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ANALYZING  MODE  CONFUSION  VIA  MODEL  CHECKING 

GERALD  LUTTGEN*  AND  VICTOR  CARRENCd 


Abstract.  Mode  confusion  is  one  of  the  most  serious  problems  in  aviation  safety.  Today’s  complex 
digital  flight  decks  make  it  difficult  for  pilots  to  maintain  awareness  of  the  actual  states,  or  modes ,  of  the 
flight  deck  automation.  NASA  Langley  leads  an  initiative  to  explore  how  formal  techniques  can  be  used  to 
discover  possible  sources  of  mode  confusion.  As  part  of  this  initiative,  a  flight  guidance  system  was  previously 
specified  as  a  finite  Mealy  automaton,  and  the  theorem  prover  PVS  was  used  to  reason  about  it. 

The  objective  of  the  present  paper  is  to  investigate  whether  state- exploration  techniques ,  especially  model 
checking ,  are  better  able  to  achieve  this  task  than  theorem  proving  and  also  to  compare  several  verification 
tools  for  the  specific  application.  The  flight  guidance  system  is  modeled  and  analyzed  in  Mur</>,  SMV,  and 
Spin.  The  tools  are  compared  regarding  their  system  description  language ,  their  practicality  for  analyzing 
mode  confusion,  and  their  capabilities  for  error  tracing  and  for  animating  diagnostic  information.  It  turns 
out  that  their  strengths  are  complementary. 

Key  words,  mode  confusion,  model  checking,  modeling,  state  exploration,  verification  tools 

Subject  classification.  Computer  Science 

1.  Introduction.  Although  digital  system  automation  in  the  flight  deck  of  aircrafts  has  contributed  to 
aviation  safety ,  we  are  starting  to  experience  some  undesirable  side  effects  as  a  result  of  the  high  degree  of 
automation.  Automation  has  significantly  reduced  the  overall  pilot  workload;  however,  in  some  instances  the 
workload  has  just  been  re-distributed,  causing  short  periods  of  very  high  workloads.  This  is  usually  the  case 
during  transition  periods  when  the  aircraft  moves  from  one  phase  of  flight  to  another  or  when  data  re-entry 
is  necessary  due  to,  e.g.,  route  changes.  It  is  during  these  transitional  phases  that  pilots  may  get  confused 
about  the  states,  or  modes ,  of  the  flight  deck  automation.  Mode  confusion  may  cause  pilots  to  interact 
inappropriately  with  the  on-board  automation,  with  possibly  catastrophic  consequences.  Indeed,  incidents 
and  accidents  in  aviation  are  increasingly  attributed  to  this  aspect  of  pilot-automation  interaction  [2]. 

NASA  Langley  Research  Center,  in  partnership  with  avionics  manufacturers  and  other  organizations, 
is  engaged  in  a  program  to  explore  ways  to  minimize  the  impact  of  mode  confusion  on  aviation  safety. 
One  approach  being  studied  is  to  identify  the  sources  of  mode  confusion  by  formally  modeling  and  analyzing 
avionics  systems  in  order  to  determine  if  such  sources  exist  in  the  systems.  The  mode  logic  of  a  flight  guidance 
system  was  selected  as  a  target  system  to  develop  this  approach  and  to  determine  its  feasibility.  The  flight 
guidance  system  offers  a  realistic  avionics  system  and  has  been  modeled  and  specified  in  many  notations 
and  languages  including  CoRE  [9,  21],  SCR  [14,  20],  Z  [10,  31],  ObjecTime  [22,  28],  and  PVS  [5,  25].  In  the 
PVS  effort,  the  behavior  of  the  flight  guidance  system  was  encoded  as  a  finite  state  machine.  Properties, 
identified  as  possible  sources  of  mode  confusion  by  engineers,  pilots,  and  experts  in  human  factors  [18],  were 
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defined  in  the  PVS  language.  Some  of  these  properties  include  inconsistent  behavior ,  ignored  crew  inputs , 
and  indirect  mode  changes .  Proofs  in  the  PVS  model,  which  encodes  a  Mealy  automaton,  were  undertaken  to 
either  show  that  a  property  holds  or  to  discover  conditions  that  preclude  the  property  from  becoming  true. 
The  employed  style  of  theorem  proving  resembles  a  form  of  state  exploration.  Hence,  the  question  arises 
whether  state  exploration  techniques,  such  as  model  checking  [6,  8,  26],  are  better  suited  for  this  task.  The 
issues  to  be  considered  are  whether  model  checking  techniques  are  appropriate,  whether  the  modeling  and 
verification  consumes  less  resources  than  theorem  proving,  and  whether  unsuccessful  verification  attempts 
return  sufficient  information  which  lead  an  engineer  to  potential  design  flaws.  In  order  to  get  answers 
to  our  questions,  we  model  and  analyze  the  mode  logic  by  applying  three  popular  and  publicly  available 
Mate- exploration/model- checking  tools ,  namely  Mur0  [7,  23],  SMV  [19,  29],  and  Spin  [15,  30]. 

The  results  of  this  paper  show  that  all  three  model  checking  tools  have  the  capability  of  modeling  the 
mode  logic  of  the  flight  guidance  system  and  analyzing  properties  related  to  mode  confusion.  However, 
each  verification  tool  has  its  own  strengths  and  weaknesses.  Therefore,  we  put  our  emphasis  on  comparing 
the  suitability  of  Mur</>,  SMV,  and  Spin  in  the  context  of  our  application.  We  draw  our  comparison  along 
three  aspects:  (1)  the  suitability  of  the  tools’  languages  for  modeling  the  mode  logic,  (2)  the  suitability  of 
the  tools  for  specifying  and  verifying  the  mode  confusion  properties  of  interest,  and  (3)  the  tools’  ability  to 
generate  and  animate  diagnostic  information .  The  first  aspect  is  of  importance  because  it  influences  the  way 
in  which  we  model  the  example  system.  The  second  aspect  refers  to  the  expressiveness  of  the  language  in 
which  system  properties  are  encoded,  and  also  to  the  degree  of  orthogonality  between  the  specification  of 
the  system  and  the  specification  of  its  properties.  The  third  aspect  is  perhaps  the  most  important  one  for 
engineers  since  system  designs  are  often  incorrect  in  early  design  stages.  Finally,  it  should  be  noted  that  our 
comparative  case  study  is  not  intended  to  determine  which  verification  tool  is  ‘the  best.’  All  comparisons 
made  only  refer  to  a  certain  class  of  applications;  the  main  characteristics  of  the  flight  guidance  system  are 
its  synchronous ,  reactive ,  and  deterministic  behavior. 

The  remainder  of  this  paper  is  organized  as  follows.  Section  2  gives  an  overview  of  the  flight  guidance 
system,  of  its  mode  logic,  and  of  potential  sources  for  mode  confusion.  Sections  3,  4,  and  5  show  the  modeling 
and  analysis  of  the  mode  logic  in  Mur<^,  SMV,  and  Spin,  respectively.  Section  6  discusses  the  strengths  of 
each  verification  tool  for  our  application  and  refers  to  related  work,  while  Section  7  contains  our  conclusions 
and  directions  for  future  work.  Finally,  the  appendices  include  the  full  models  of  the  mode  logic. 

2.  Flight  Guidance  Systems  and  Mode  Logics.  The  flight  guidance  system  is  a  central  component 
of  the  flight  control  system  (see  Fig.  2.1).  It  continuously  determines  the  difference  between  the  actual  state 
of  an  aircraft  -  its  position,  speed,  and  attitude  as  measured  by  its  sensors  -  and  its  desired  state  as  given  by 
the  crew  and/or  the  flight  management  system.  In  response,  the  flight  guidance  system  generates  commands 
to  minimize  this  difference,  which  the  autopilot  may  translate  into  movements  of  the  aircraft’s  actuators. 
These  commands  are  calculated  by  control  law  algorithms  that  are  selected  by  the  mode  logic . 


Fig.  2.1.  Flight  control  system. 
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In  the  following  we  focus  on  the  mode-logic  part  of  flight  guidance  systems.  Especially,  we  leave  out 
the  modeling  of  the  control  laws  and,  if  no  confusion  arises,  use  interchangeably  the  terms  flight  guidance 
system  and  mode  logic.  For  the  purposes  of  this  paper,  it  sufflces  to  understand  the  functionality  of  the 
mode  logic  and  how  it  is  decomposed  into  sub-components.  The  flight  guidance  system  essentially  acts  as 
a  deterministic  machine  which  is  composed  of  several  synchronous  sub-machines.  It  receives  events  from 
its  environment  -  i.e.,  the  crew  interface ,  the  aircraft’s  sensors ,  and  the  flight  management  system  -  in  a 
nondeterministic  fashion  and  reacts  to  them  by  changing  its  state  appropriately.  The  functionality  of  a  flight 
guidance  system  varies  with  application,  vendor,  customer  preferences,  and  other  factors. 

Fig.  2.2  shows  a  typical  mode  logic  for  a  business  jet/commuter  jet  flight  guidance  system.  The  mode 
logic  can  be  represented  and  modeled  by  three  interacting  components:  the  lateral  guidance ,  the  vertical 
guidance ,  and  the  flight  director.  The  mode  of  the  flight  director  -  which  can  be  either  cues ,  no- cues ,  or  off 
-  determines  whether  or  not  the  flight  guidance  system  is  being  used  as  a  navigational  aid  either  manually 
by  the  crew  or  automatically  through  the  autopilot.  The  lateral  guidance  subsumes  the  roll  mode  (Roll), 
the  heading  mode  (HDG),  the  navigation  mode  (NAV),  and  the  lateral  go-around  mode  (LG A),  whereas 
the  vertical  guidance  subsumes  the  pitch  mode  (Pitch),  the  vertical  speed  mode  (VS),  and  the  vertical  go- 
around  mode  (VGA).  Each  mode  can  be  either  cleared  or  active ,  with  the  navigation  mode  having  additional 
sub-states  in  the  active  state.  The  behavior  of  each  component  places  constraints  on  the  other  components. 
For  example,  when  the  flight  director  is  on,  there  must  be  exactly  one  mode  active  in  the  lateral  guidance 
and  one  mode  active  in  the  vertical  guidance.  In  some  situations,  an  external  event  may  require  several 
simultaneous  mode  changes.  Indeed,  the  behavior  of  the  flight  guidance  system  reflects  a  kind  of  two-level 
semantics  similar  to  Statecharts  [13],  where  both  semantic  levels  are  not  independent  but  connected  via  the 
synchrony  hypothesis  [1].  This  hypothesis  guarantees  that  a  system  completes  its  reaction  to  an  external 
event  before  the  next  external  event  arrives. 


Mode  Logic 

Lateral  Guidance 

Vertical  Guidance 

Flight  Director 

I 

VGA 

Fig.  2.2.  Architecture  of  the  model  logic  of  the  flight  guidance  system. 


Before  we  discuss  the  modeling  of  the  flight  guidance  system  within  the  verification  tools  Mur<^,  SMV, 
and  Spin,  we  briefly  mention  some  properties  of  our  system,  which  can  be  classified  as  mandatory  properties 
and  mode  confusion  properties .  Some  of  the  former  properties  are:  (i)  if  the  flight  director  is  off,  all  lateral 
and  vertical  guidance  modes  must  be  cleared,  (ii)  if  the  flight  director  is  on,  then  exactly  one  lateral  and  one 
vertical  mode  is  active,  and  (iii)  the  lateral  and  vertical  default  modes  are  activated  when  the  flight  director 
is  on  and  when  all  other  modes  are  cleared.  These  and  other  mandatory  properties  must  be  true  if  we  have 
accurately  modeled  the  system.  Regarding  mode  confusion,  several  categories  are  identified  in  [18].  We  have 
selected  three  categories  to  use  in  the  analysis  of  our  system:  (1)  inconsistent  behaviors ,  i.e.,  a  crew  interface 
input  (switch,  dial,  etc.)  has  different  functionality  for  different  system  states,  (2)  ignored  operator  inputs , 
i.e.,  a  crew  input  does  not  result  in  a  change  of  state,  and  (3)  indirect  mode  changes ,  i.e.,  the  system  changes 
its  state  although  no  crew  input  is  present.  To  discover  if  there  are  possible  sources  of  mode  confusion,  we 
formulate  the  negation  of  each  property  -  there  are  no  inconsistent  behaviors,  no  ignored  inputs,  and  no 
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indirect  mode  changes  -  and  try  to  prove  it.  Conditions  that  prevent  us  from  successfully  completing  the 
proof,  manifested  by  unprovable  subgoals  in  a  theorem  prover  and  error  traces  in  model-checking  tools,  are 
the  ones  we  intend  to  uncover.  As  expected,  this  process  is  labor  intensive  when  using  theorem  proving  [22]. 
The  work  described  here  investigates  if  model  checking  is  a  more  efficient  way  of  performing  the  analysis. 

3.  Modeling  the  Mode  Logic  in  Mur0.  The  Murej)  Verification  System  [7,  23],  a  state-exploration 
tool  developed  by  David  Dill’s  group  at  Stanford  University,  consists  of  a  compiler  and  a  description  language. 
The  compiler  takes  a  Mur<p  description  and  generates  a  C++  special-purpose  verifier  for  it.  This  verifier  can 
then  be  used  for  checking  assertions  and  deadlock  behavior  of  the  system  under  consideration. 

The  Mur</>  description  language  is  a  high-level  language  which  borrows  from  many  constructs  found 
in  programming  languages,  such  as  Pascal.  It  may  be  used  to  model  synchronous  as  well  as  asynchronous 
hardware  and  software  systems  which  can  be  compiled  into  finite  Kripke  structures ,  i.e.,  finite  automata  whose 
states  are  attached  with  the  semantic  information  of  interest.  Mur</>  descriptions  may  include  declarations  of 
constants ,  finite  data-types  (such  as  Booleans,  enumeration  types,  finite  subranges  of  integers,  record  types, 
and  array  types),  global  and  local  variables ,  and  unhested  procedures  and  functions.  Moreover,  they  contain 
transition  rules  for  describing  system  behavior,  a  description  of  the  initial  states ,  and  a  set  of  state  invariants 
and  assertions.  Each  transition  rule  may  consist  of  a  guard  ~  which  is  never  needed  in  our  application  scenario 
-  and  an  action ,  i.e.,  a  statement  which  modifies  the  values  of  global  variables.  A  state  in  Murk’s  execution 
model  is  an  assignment  to  all  global  variables  in  the  description  under  investigation.  A  transition  is  then 
determined  by  a  rule,  taken  nondeterministically  from  the  set  of  transition  rules  whose  condition  is  true  in 
the  current  state.  The  rule’s  execution  updates  all  or  some  global  variables  according  to  its  action. 

Table  3.1 

Specification  of  module  simple  guidance  in  Mur<j> 


TYPE  sg.modes 
TYPE  sg_e vents 
TYPE  -sg.signals 


:  ENUM  {  cleared,  active  }; 

:  ENUM  {  activate,  deactivate,  switch,  clear  }; 
:  ENUM  {  null,  activated,  deactivated  >; 


PROCEDURE  simple__guidance(VAR  mode  :sg_modes ;  event : sg.events;  VAR  signal :  sg_signals)  ; 
BEGIN 


IF  mode=cleared 

THEN  SWITCH 

event  CASE 

activate 

:  signal  : = 

activated; 

mode  :=  active; 

CASE 

deactivate 

:  signal  := 

null ; 

CASE 

switch 

:  signal  := 

activated; 

mode  :=  active; 

CASE 

clear 

:  signal  := 

null ; 

END; 

ELSE 

SWITCH 

event  CASE 

activate 

:  signal  := 

null; 

CASE 

deactivate 

:  signal  := 

null; 

mode  : =  cleared 

CASE 

switch 

;  signal  := 

deactivated; 

mode  :=  cleared 

CASE 

clear 

:  signal  := 

deactivated; ' 

mode  :*  cleared 

END; 


END;  END; 


In  the  center  of  the  Mur</>  model  of  the  flight  guidance  system  is  the  deterministic  procedure  fgs.  This 
procedure  encodes  the  system’s  reaction  to  some  environment  event  env_ev  entering  the  mode  logic.  For 
the  purposes  of  this  paper  it  is  not  important  to  name  the  fourteen  different  environment  events  interacting 


with  the  mode  logic.  However,  by  declaring  a  transition  rule  for  each  environment  event  env_ev  as  RULE 
HruleJor_env_event"  BEGIN  fgs(env„ev);  END,  we  model  the  nondeterministic  behavior  of  the  environ¬ 
ment  which  arbitrarily  chooses  the  event  entering  the  system  at  each  synchronous  step.  Please  observe  that 
our  encoding  of  the  environment  does  not  require  us  to  store  event  names  explicitly  in  a  global  variable,  but 
rather  to  inject  them  to  f  gs  via  a  call-by-value  parameter.  Due  to  space  constraints  we  do  not  completely 
specify  procedure  fgs  here.  Instead,  we  concentrate  on  modeling  the  vertical-guidance  component  of  the 
flight  guidance  system.  Let  us  define  the  modes  of  the  vertical-guidance  component  as  instantiations  of  an 
abstract  data-type  module  simple_guidance,  specified  in  Mur (j)  as  procedure,  which  encodes  each  mode’s 
behavior  as  a  Mealy  automaton  behaving  like  a  Boolean  switch  (cf.  Table  3.1).  The  module  is  parameterized 
by  the  mode  mode  under  consideration  (as  call-by-reference  parameter),  the  input  event  event  (as  call-by- 
value  parameter),  and  the  output  event  signal  (as  call-by-reference  or  return  parameter).  The  parameters 
are  of  enumeration  types  sgjnode,  sg_events,  and  sg_signals,  respectively,  where  type  sgjnode  ranges  over 
the  values  cleared  and  active,  type  sg.event  ranges  over  activate,  deactivate,  switch,  and  clear,  and 
type  sg_signal  ranges  over  null,  activated,  and  deactivated.  The  body  of  simple_guidance  specifies 
the  reaction  of  a  mode  to  input  event  event,  with  respect  to  its  current  state  mode.  This  reaction  is  described 
by  an  if- statement,  two  case- selections,  and  assignments  to  variable  mode  and  return  parameter  signal. 

Table  3.2 

Specification  of  module  vertical  guidance  in  Mur<j> 


VAR  pitch,  vs,  vga  :  sg_modes; 


PROCEDURE  vertical_guidance(env_ev:env_events) ; 

VAR  sig  :  sg.signals; 

BEGIN  CLEAR  sig; 

IF  pitch.event (env_ev)  THEN  simple.guidance (pitch,  pitch_conv(env_ev) ,  sig); 

IF  sig=activated  THEN  simple_guidance(vs , 

simple.guidance (vga , 


END; 

ELSIF  vs_event (env_ev)  THEN  simple_guidance(vs ,  vs_conv(env_ev) ,  sig); 

IF  sig=activated  THEN  simple.guidance (pitch, 

simple_guidance (vga, 

ELSIF  sig=deactivated  THEN  simple_guidance (pitch, 
END; 

ELSIF  vga_event (env_ev)  THEN  simple_guidance(vga,  vga_conv(env_ev) ,  sig); 

IF  sig=activated  THEN  simple.guidance (pitch, 

simple.guidance (vs , 

ELSIF  sig=deactivated  THEN  simple_guidance (pitch, 
END; 


deactivate,  sig); 
deactivate,  sig); 

deactivate ,  sig) ; 
deactivate,  sig); 
activate,  sig); 

deactivate,  sig); 
deactivate,  sig); 
activate,  sig); 


END;  END; 


We  can  now  specify  the  vertical-guidance  module  as  a  procedure,  called  vert ical_gui dance  (cf.  Ta¬ 
ble  3.2),  by  employing  procedure  simple_guidance  for  describing  the  behavior  of  the  modes  pitch,  vs,  and 
vga,  which  are  defined  as  global  variables.  The  task  of  procedure  vertical_guidance  is  firstly  to  recognize 
whether  the  environment  event  env_ev  passed  to  the  system  refers  to  mode  Pitch,  to  mode  VS,  or  to  mode 
VGA.  This  is  achieved  with  help  of  the  three  auxiliary  functions  pitch_event,  vs_event,  and  vga_event,  re- 
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spectively.  Then  env_ev  is  translated  to  an  event  of  type  sg.events  via  the  auxiliary  functions  pitch_conv, 
vs_conv}  and  vga.conv,  respectively,  and  passed  to  the  mode  to  which  it  belongs.  If  this  mode  is  activated 
by  the  event,  i.e.,  simple-guidance  returns  value  activated  via  local  variable  sig,  then  the  other  two 
modes  must  instantly  be  deactivated  by  invoking  simple^guidance  with  respect  to  the  appropriate  modes 
and  event  deactivate.  It  should  be  mentioned  that  the  above  modeling  of  components  simple^guidance 
and  vertical-guidance  is  carried  over  one-to-one  from  the  PVS  model  of  the  flight  guidance  system,  which 
was  developed  by  NASA  Langley  and  Rockwell  Collins  [5,  22].  In  fact,  every  PVS  construct  used  in  [22] 
corresponds  to  a  construct  in  Murk’s  description  language.  However,  we  sometimes  find  it  useful  to  translate 
functions  in  PVS  to  procedures  in  Mur^  that  have  an  additional  call- by-reference  parameter  for  returning 
the  computed  value.  In  PVS,  only  functions  can  be  specified,  although  procedures  would  sometimes  be  more 
preferable  from  a  software-engineering  point  of  view. 

Table  3.3 

Specification  of  some  mode  confusion  properties  in  Mur<f 


VAR  old.pitch,  old.vs,  old_vga  :  sg.modes; 

PROCEDURE  mode_confusion_properties(env_ev:env_events) ; 

BEGIN 

ALIAS  mode_change  :  pitch  !=  old.pitch  I  vs  !=  old.vs  I  vga  !=  old.vga;  DO 
IF  env_ev=vs_switch_hit  THEN 

—  check  for  response  to  pressing  VS  button 
assert  (old_vs=cleared  ->  vs=active  )  "vs.toggle.l" ; 
assert  (old_vs=active  ->  vs=cleared)  Mvs_toggle_2" ; 

END; 

—  search  for  ignored  crew  inputs  (property  violated) 

assert  (crew.input (env_ev)  ->  mode.change)  "search.for.ignored.crew.inputs" ; 

—  no  unknown  ignored  crew  inputs 

assert  ( (crew_input (env.ev)  &  ! ignored. crew. input (ev))  ->  mode.change)  "no.unknown.ignored" ; 

—  search  for  indirect  mode  changes  (property  violated) 

assert  ( ! crew.input (env.ev)  ->  !mode_change)  "search.f or.indirect.mode.changes" ; 

--  no  unknown  indirect  mode  changes 

assert  ((! crew.input (env.ev)  &  ! indirect.mode.change (env.ev) )  ->  Imode.change)  "no.unknown. . . " ; 
END; 

—  update  state  variables 

old.pitch  :=  pitch;  old.vs  :=  vs;  old. vga  :=  vga; 

END; 


We  now  turn  our  focus  to  specifying  mode  confusion  properties.  As  states  are  generated  by  the  Mur^ 
verifier,  assert  statements,  that  were  explicitly  included  in  the  action  of  a  rule,  are  checked.  If  some 
assertion  is  violated  -  i.e.,  the  assert  statement  is  evaluated  to  false  in  some  reachable  system  state  - 
the  Mur</>  verifier  halts  and  outputs  the  string  which  the  user  associated  with  the  assert  statement  under 
consideration.  Moreover,  the  verifier  outputs  diagnostic  information  which  consists  of  a  sequence  of  states 
leading  from  the  initial  state  to  the  error  state.  The  verifier  also  halts  if  the  current  state  possesses  no 
successor  states,  i.e.,  if  it  is  deadlocked.  Let  us  return  to  the  three  categories  of  mode  confusion  mentioned 
in  Section  2  by  showing  how  an  exemplary  property  of  each  category  can  be  stated  as  an  assertion. 
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In  the  system  description  of  our  mode  logic,  we  encapsulate  all  assertions  in  the  single  procedure 
mode_confusion_properties,  which  is  invoked  as  the  last  statement  in  procedure  fgs  and  which  takes 
the  current  environment  event  env..ev  as  parameter  (cf.  Table  3.3;  the  notation  w~  introduces  a  comment 
line  in  Mur 0,  !=  denotes  inequality ,  and  I ,  &,  !,  and  ->  stand  for  logical  disjunction ,  conjunction ,  negation , 
and  implication ,  respectively).  Since  all  mode  confusion  properties  of  interest  concern  the  transition  from 
onp  system  state  to  the  next,  we  need  to  store  the  global  variables’  values  of  the  previously  visited  state. 
For  this  purpose,  we  introduce  new  global  variables  old„pitch,  old_vs,  and  old-vga.  The  need  for  this 
overhead  arises  because  Murk’s  verification  capabilities  are  restricted  to  reason  about  simple  state  invariants 
only  and  not  about  more  general  “ state  transition  invariants”  Therefore,  such  state  transition  invariants 
need  to  be  encoded  as  state  invariants,  which  doubles  the  size  of  the  state  vector  for  our  system  description. 
The  first  two  assertions  in  Table  3.3,  belonging  to  the  first  category  of  mode  confusion  properties,  state  that 
environment  event  vs_switchJhit  acts  like  a  toggle  with  respect  to  mode  VS,  i.e.,  (i)  if  mode  VS  was  in 
state  cleared  and  event  vs_switch_hit  arrived,  then  it  is  now  in  state  active,  and  (ii)  analogously  with 
exchanged  roles  of  cleared  and  active. 

As  example  of  the  second  category  of  mode  confusion  properties,  we  check  whether  no  crew  inputs 
are  ignored,  i.e.,  whenever  an  event  that  originated  from  the  crew  enters  the  mode  logic,  then  at  least 
one  global  variable  changes  its  value.  We  can  specify  this  property  as  implication  crew.input  (env_ev) 
->  mode_change,  where  crew_input  is  a  Boolean  function  determining  whether  environment  event  env_ev 
originates  from  the  crew  and  where  mode.change  is  a  shortcut,  introduced  as  an  ALIAS  statement  in  Mur<£.  As 
expected  (cf.  Section  2),  this  mode  confusion  property  does  not  always  hold.  Using  the  error  trace  returned 
by  Mur 0  helps  us  in  identifying  the  causes,  as  is  our  objective.  We  do  not  go  into  the  details  here  but  mention 
that  we  filter  out  the  identified  cause  by  including  an  additional  predicate  ignored_crew„input,  stating  the 
negation  of  the  cause,  in  the  premise  of  the  assertion  (cf.  Table  3.3).  We  then  re-run  the  Mur0  verifier  and 
iterate  the  described  process  until  the  assertion  becomes  true,  thereby  gradually  capturing  all  crew-input 
scenarios  responsible  for  mode  confusion.  When  comparing  our  approach  to  the  one  taken  in  PVS  [22]  - 
i.e.,  trying  theorem  proving  until  either  obtaining  proof  goal  true  or  until  reaching  an  unsatisfiable  proof 
goal  -  we  feel  that  ours  is  more  effective.  We  discovered  that  the  variant  of  ignored_crew_input  used  in 
the  PVS  model  is  stronger  than  necessary,  thereby  wrongfully  identifying  some  situations  as  sources  of  mode 
confusion.  The  difficulty  with  the  analysis  in  PVS  is  the  following.  Mur</>  returns  error  traces  that  pinpoint 
the  condition  violating  the  assertion,  whereas  in  a  PVS  failed  proof  the  condition  must  be  extracted  from 
a  proof  sequent  consisting  of  assertions  and  subgoals.  Extracting  conditions  from  a  proof  sequent  is  often 
more  time-consuming  and  usually  requires  a  better  understanding  of  the  system’s  behavior. 

Similar  to  the  assertion  “checking  for  ignored  crew  inputs”  we  approach  the  third  category  of  mode 
confusion  properties.  The  property  we  consider  is  “no  indirect  mode  changes”  which  prohibits  a  system’s 
state  to  change  if  the  current  environment  event  is  not  originated  by  the  crew.  Using  Mur</>,  we  discover 
the  conditions  that  invalidate  this  property.  As  before,  we  weaken  the  property  by  introducing  a  predicate 
indirect  .mode  .change,  until  all  sources  of  indirect  mode  changes  are  detected.  The  mandatory  properties 
mentioned  in  Section  2  are  formalized  as  Mur</>  invariant  statements  and  proved.  The  difference  between  an 
assert  statement  and  an  invariant  statement  in  Mur (j)  is  that  the  former  appears  in  the  system  description 
part  of  the  model,  while  the  latter  is  orthogonal  to  the  system  description.  The  reason  for  specifying  mode 
confusion  properties  in  the  system  description  is  their  reference  to  the  auxiliary  variables  old.pitch,  old.vs, 
and  old_vga.  In  order  to  keep  the  state  space  small,  the  auxiliary  variables  must  be  re-assigned  to  the  actual 
values  of  pitch,  vs,  and  vga,  respectively,  before  a  step  of  the  synchronous  system  is  completed. 
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Summarizing,  Murk’s  description  language  turned  out  to  be  very  useful  for  our  task,  especially  since  the 
already  developed  PVS  model  of  the  flight  guidance  system  [22]  could  be  simply  carried  over.  Unfortunately, 
Murk’s  capability  for  expressing  system  properties  is  quite  restrictive,  forcing  us  to  encode  state  transition 
invariants  as  state  invariants,  thereby  doubling  the  number  of  global  variables  and,  as  a  consequence,  Murk’s 
memory  requirements.  The  full  Mur</>  model  subsumes  about  30  assertions  and  leads  to  a  Kripke  structure 
having  242  states.  In  each  state  of  the  Kripke  structure  any  of  the  14  environment  events  may  potentially 
enter  the  system;  this  gives  3  388  =  242  x  14  transitions  in  total.  The  state-space  exploration  undertaken 
by  the  Mur 0  verifier  took  under  2  seconds  on  a  SUN  SPARCstation  20.  This  is  an  impressive  result  when 
compared  to  the  semi-automatic  proofs  in  PVS  [22]. 

4.  Modeling  the  Mode  Logic  in  SMV.  The  SMV  system  [19,  29],  originally  developed  by  Ken 
McMillan  at  Carnegie-Mellon  University,  is  a  model- checking  tool  for  verifying  finite-state  systems ,  described 
in  a  simple  description  language,  against  specifications  in  the  temporal  logic  CTL  [6,  8].  The  SMV  verifier 
implements  a  symbolic  model-checking  algorithm  [4]  based  on  Binary  Decision  Diagrams  (BDDs)  [3]. 

SMV’s  description  language  is  a  very  simple,  yet  elegant  language  for  specifying  finite  Kripke  structures, 
which  has  the  feel  of  a  hardware  description  language.  The  language’s  data  types  are  Booleans  (where  false 
and  true  are  encoded  as  0  and  1,  respectively),  enumeration  types ,  and  arrays.  Its  syntax  resembles  a  style 
of  parallel  assignments ,  and  its  semantics  is  similar  to  single  assignment  data  flow  languages.  For  structuring 
specifications,  SMV  allows  modular  hierarchical  descriptions.  In  contrast  to  Mur0,  SMV  descriptions  are  not 
compiled  into  a  special-purpose  verifier,  but  are  interpreted  instead.  The  interpreter  makes  sure  that  the 
specified  system  is  indeed  implementable  by  checking  for  multiple  assignments  to  the  same  variable,  circular 
assignments ,  and  type  errors.  The  SMV  language  also  includes  constructs  for  stating  system  specifications 
in  the  temporal  logic  (fair)  CTL  [8],  which  allows  one  to  express  a  rich  class  of  temporal  properties,  including 
safety ,  liveness ,  and  fairness  properties.  In  the  present  application  of  the  synchronous  flight  guidance  system, 
we  focus  on  safety  properties,  to  which  invariants  belong. 

Table  4.1 

Specification  of  module  simple  guidance  in  SMV 


MODULE  simple_guidance (activate,  deactivate,  switch,  clear) 
VAR  mode  :  {cleared,  active}; 

ASSIGN  init(mode)  :=  cleared; 

next (mode)  :=  case  deactivated  |  deactivate  :  cleared; 

activated  :  active; 

1  :  mode; 

esac; 

DEFINE  activated  :=  (mode=cleared)  &  (activate  |  switch); 

deactivated  :=  (mode=active  )  &  (clear  |  switch); 


A  module  description  in  SMV  consists  of  four  parts:  (1)  the  MODULE  clause,  stating  the  module’s  name 
and  a  list  of  formal  (call-by-reference)  parameters,  (2)  the  VAR  clause,  declaring  (global)  variables  needed  for 
describing  the  module’s  behavior,  (3)  the  ASSIGN  clause,  which  specifies  the  initial  value  of  all  variables  (cf. 
init)  and  how  each  variable  is  updated  from  state  to  state  (cf.  next),  and  (4)  the  DEFINE  clause,  which  allows 
one  to  introduce  abbreviations  for  more  complex  terms.  Similar  to  the  Mur (j)  model,  the  main  module  MAIN 
of  our  SMV  specification  encodes  the  environment  of  the  flight  guidance  system,  which  nondeterministically 
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sends  events  to  the  mode  logic.  This  is  done  by  defining  variable  env_ev  of  enumeration  type  env_events, 
which  contains  all  environment  events,  and  by  adding  “init(env_ev)  :=  env^events;  next(env_ev)  :  = 
env^events”  to  the  ASSIGN  clause.  Analogous  to  the  Mu  ref)  model,  we  specify  a  module  simple_guidance 
(see  Table  4.1)  and,  thereby,  show  how  Mealy  machines  may  be  encoded  in  SMV.  Module  simple -guidance 
takes  the  four  input  events  activate,*  deactivate,  switch,  and  clear  -  which  can  be  either  absent  or 
present  -  as  parameters.  The  state  associated  with  simple^guidance  is  variable  mode  which  may  adopt 
values  cleared  and  active.  Note  that  the  values  of  enumeration  types  are  encoded  by  the  SMV  interpreter 
using  a  collection  of  Boolean  variables,  such  that  transition  relations  can  be  represented  by  BDDs.  The 
initial  value  init(mode)  of  mode  is  cleared.  The  behavioral  part  of  simple^guidance  is  described  in  the 
next  (mode)  statement,  which  consists  of  a  case  expression.  The  value  of  this  expression  is  determined  by 
the  first  expression  on  the  right  hand  side  of  the  colon  such  that  the  condition  on  the  left  hand  side  is 
true.  The  symbols,  =,  &,  and  I  stand  for  equality ,  logical  conjunction ,  and  logical  disjunction ,  respectively. 
The  terms  activated  and  deactivated  are  defined  as  abbreviations  of  more  complex  terms  in  the  DEFINE 
clause.  The  values  of  mode,  activated  and  deactivated  are  accessible  from  outside  the  module.  Therefore, 
a  DEFINE  clause  may  be  used  for  encoding  output  events  of  Mealy  automata. 


Table  4.2 

Specification  of  module  vertical  guidance  in  SMV 


MODULE  vertical_guidance(vs_pitch_wheel_changed,  vs_switch_hit ,  ga_switch_h.it, 

sync_switch_pressed,  ap_engaged_event) 

VAR  pitch  :  s imple ..guidance  (pit ch.acti vat e,  pitch_deactivate,  0,  0) 

vs  :  simple_guidance(  0,  vs_deactivate,  vs_switch_hit ,  0) 

vga  :  simple_guidance(  0,  vga_deactivate ,  ga_switch_hit ,  vga.clear) 


DEFINE  pitch_activate 

pitch_deactivate 

vs_deactivate 

vga_deactivate 

vga.clear 

pitch_event 

vs_event 

vga_event 


=  (vs_event  &  vs .deactivated)  |  (vga_event  &  ga. deactivated) 

vs_pitch_wheel_changed ; 

=  (vs_event  &  vs . activated)  |  (vga.event  &  ga. activated) ; 

=  (pit ch_e vent  &  pitch. activated)  I  (vga_event  &  ga. activated) ; 

=  (pitch.event  &  pitch. activated)  |  (vs_event  &  vs .activated) ; 

=  ap_engaged_event  I  sync_switch_pressed; 

=  vs_pitch_vheel_changed; 

=  vs_switch  Jiit ; 

=  ap_ engaged. event  I  sync_switch_pressed  | 
ga_switch_hit; 


Before  we  model  the  vertical  guidance  component,  we  comment  on  why  we  have  encoded  the  input 
event  of  the  simple-guidance  Mealy  machine  using  four  different  signal  lines  -  i.e.,  adopting  a  hardware- 
description  language  point  of  view  -  instead  of  a  single  event  of  some  enumeration  type  subsuming  all  four 
values.  If  activate,  deactivate,  switch,  and  clear  were  combined  in  an  enumeration  type,  a  syntactic 
-  though  not  semantic  -  circularity  would  be  introduced  which  could  not  be  resolved  by  SMV,  i.e.,  our 
description  of  the  mode  logic  would  be  rejected.  Another  difference  between  simple_guidance  as  a  module 
in  SMV  and  as  an  abstract  data-type  in  Mur0  is  that  the  mode  variable  is  encapsulated  within  the  SMV 
module,  whereas  it  is  a  call-by-reference  parameter  in  Murk’s  abstract  data  type.  We  feel  that  SMV  reflects 
the  architecture  of  the  flight  guidance  system  better,  since  mode  belongs  to  component  simple_guidance 
and  should  not  be  declared  outside. 


9 


The  behavior  of  each  mode  of  the  vertical  guidance  model  (cf.  Table  4.2),  Pitch,  VS,  and  VGA,  can 
now  be  described  by  instantiating  the  module  simple -guidance,  as  is  done  in  the  VAR  clause  of  module 
vertical-guidance.  Thereby,  global  variables  pitch. mode,  vs. mode,  and  vga.mode  are  created  as  part 
of  the  state  vector  of  our  SMV  model.  All  actual  parameters  of  each  simple ^guidance  module  can  be 
specified  as  Boolean  terms  on  the  input  parameters  of  module  vertical -guidance,  which  are  essentially 
environment  events  triggering  an  action  regarding  the  vertical  aircraft  axis.  Note  that  the  Boolean  functions 
pitch-event,  vs.event,  and  vga.event  used  in  the  Mur (j)  description  are  encoded  here  in  the  DEFINE  clause  of 
vertical^guidance.  Our  modeling  of  vertical-guidance  is  self-explanatory  and  visualizes  the  differences 
between  the  SMV  and  the  Mu r<f>  languages.  While  in  Mur 0  each  synchronous  step  of  the  flight  guidance 
system  can  be  modeled  by  a  sequential  algorithm ,  it  must  be  described  in  SMV  by  parallel  assignments . 

Table  4.3 

Specification  of  some  mode  confusion  properties  in  SMV 


DEFINE  mode.change  :=  ! (vertical. pitch. mode  =  cleared  <->  AX  vertical. pitch. mode  =  cleared)  I 

!  (vertical,  pitch,  mode  =  active  <->  AX  vertical  .pitch,  mode  =  active  )  I  ... 

—  check  for  response  to  pressing  VS  button 

SPEC  AG  (vertical. vs .mode=cleared  &  env_ev=vs_switch_hit  ->  AX  vertical. vs'.mode=active) 

SPEC  AG  (vertical.vs.mode=active  &  env_ev=vs_switch_hit  ->  AX  vertical  .vs  .mode=cleared) 

—  search  for  ignored  crew  inputs  (property  violated) 

SPEC  AG  (crew_ input  ->  mode_ change) 

—  no  unknown  ignored  crew  inputs 

SPEC  AG  (crew.input  &  ! ignored_crew_input  ->  mode_change) 

—  seaxch  for  indirect  mode  changes  (property  violated) 

SPEC  AG  (!crew_input  ->  ! mode _ change) 

—  no  unknown  indirect  mode  changes 

SPEC  AG  ((! ere w_ input  &  ! indirect _mode_change)  ->  !mode_change) 


In  SMV,  properties  are  specified  in  the  temporal  logic  Computational  Tree  Logic  (CTL)  [6,  8].  Fairness 
constraints  may  also  be  imposed  on  SMV  models  but  are  not  needed  for  our  purposes  since  we  are  strictly 
interested  in  invariants  related  to  aspects  of  mode  confusion.  In  SMV,  temporal  properties  are  introduced 
within  the  same  file  as  the  system  description  by  the  keyword  SPEC.  We  do  not  need  to  introduce  CTL 
formally  here,  as  we  use  only  a  very  limited  sublanguage  of  it.  All  of  our  properties  are  of  the  form 
A G</>,  where  AG  stands  for  “always  generally,”  i.e.,  every  state  on  every  path  through  the  system  satisfies 
property  </>.  The  formula  AX<£  expresses  that  all  successor  states  of  the  current  state  satisfy  formula  <£. 
In  this  light,  the  first  formula  in  Table  4.3,  related  to  checking  the  response  to  pressing  the  VS  button, 
states:  “every  reachable  state  in  the  underlying  Kripke  structure  of  the  model  satisfies  that,  if  mode  VS 
in  vertical-guidance  is  currently  cleared  and  event  vs_switchJiit  enters  the  system,  then  mode  VS 
in  vertical-guidance  is  active  in  every  successor  state  of  the  current  state.”  Note  that  the  symbols 
->  and  <->  used  in  Table  4.3  stand  for  logical  implication  and  equivalence ,  respectively.  The  identifiers 
mode_change,  crew_input,  indirect  .mode -change,  and  ignored_crew_input  are  abbreviations  of  Boolean 
expressions  defined  in  a  DEFINE  clause,  as  exemplarily  shown  for  mode-confusion.  The  presence  of  operator 
AX  in  CTL  remedies  the  need  to  keep  track  of  old  values  of  mode  variables.  Thereby,  the  size  of  the  associated 
state  vector  of  the  SMV  model  is  cut  in  half  when  compared  to  the  Mur</>  model.  Moreover,  a  fully  orthogonal 
treatment  of  model  and  property  specifications  is  achieved.  The  SMV  system  verified  about  thirty  assertions 
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in  slightly  more  than  half  a  second  using  438  BDD  nodes  and  allocated  less  than  1  MByte  memory  on  a 
SUN  SPARCstation  20.  The  two  properties  “ search  for  ignored  crew  inputs ”  and  “ search  for  indirect  mode 
changes ”  were  invalidated  as  in  the  Mur</>  model.  The  returned  error  traces  -  reporting  the  assignments  of 
each  variable  and  each  identifier  declared  in  a  DEFINE  clause  in  every  state  of  the  traces  -  are  of  help  in 
identifying  potential  problems  with  the  model.  SMV  also  includes  an  interactive  mode  which  provides  a  very 
simple  assistant  for  interactive  debugging.  The  state  space  of  the  SMV  model  consists  of  3388  states,  which 
corresponds  to  the  242  states  of  the  Mur<^  model  since  the  actual  environment  event  -  out  of  14  possible 
events  -  must  be  stored  in  a  variable  in  SMV  (“242  x  14  =  3388”). 

Summarizing,  SMV  performed  very  well  on  our  example  and  showed  the  suitability  of  symbolic  model 
checking  to  the  flight  guidance  system.  In  fact,  the  mode  logic’s  behavior  can  be  described  by  Boolean  terms 
and,  thus,  represented  efficiently  using  BDDs.  CTL  turned  out  to  be  an  excellent  language  for  specifying 
mode  confusion  properties  due  to  the  presence  of  next-state  operator  AX.  SMV’s  modeling  language  has 
the  feel  of  a  hardware  description  language  and  is  not  as  high  level  as  Murk’s  language.  However,  SMV’s 
module  concept  allowed  us  to  model  the  architecture ,  but  not  the  functionality,  of  the  flight  guidance  system 
one-to-one  to  the  original  PVS  specification  [22]. 


5.  Modeling  the  Mode  Logic  in  Spin.  Last,  but  not  least,  we  explore  the  utility  of  the  verification 
tool  Spin  [15,  16,  30],  which  was  developed  by  Gerard  Holzmann  at  Bell  Labs,  for  our  case  study.  Spin 
is  designed  for  analyzing  the  logical  consistency  of  concurrent  systems.  It  is  especially  targeted  towards 
modeling  and  reasoning  about  distributed  systems,  such  as  communication  protocols,  where  several  concur¬ 
rent  processes  exchange  messages  by  communicating  synchronously  via  handshaking  or  asynchronously  via 
buffered  channels.  The  description  language  of  Spin,  called  Promela,  allows  one  to  specify  nondeterministic 
processes ,  message  channels ,  and  variables  in  a  C-like  syntax.  Given  a  system  description  in  Promela,  whose 
semantics  is  again  defined  as  a  Kripke  structure,  Spin  can  -  in  contrast  to  Mur^>  and  SMV  -  perform  random 
or  interactive  simulations  of  the  system’s  execution.  Similar  to  Mur</>,  it  can  generate  a  special-purpose 
verifier,  i.e.,  a  C-program,  which  performs  an  exhaustive  exploration  of  the  system’s  state  space.  Such  a 
state  exploration  may  -  among  other  things  -  check  for  deadlocks  and  unreachable  code ,  validate  invariants , 
and  verify  properties  specified  in  a  linear-time  logic  [8,  11].  Linear-time  logic  is  not  as  expressive  as  the 
branching-time  logic  fairCTL  employed  in  SMV.  However,  it  is  rich  enough  to  specify  all  properties  of  inter¬ 
est  in  this  paper.  Spin’s  verifier  was  implemented  having  memory  efficiency  in  mind,  e.g.,  it  includes  optional 
partial-order  techniques  [12]  and  bitstate  hashing  [17]. 


Table  5.1 

Specification  of  the  main  process  init  in  Spin 


initf  env_ev=null; 
do 

: :  atomicfif 

: :  env_ev=vs_switch_hit 

fi; 

fgs(env_ev); 
env„ev=null  } 

od  } 


/*  loop  body  encodes  1  synchronous  step  */ 
/*  nondeterministic  choice  of  env.  event  */ 
/*  13  more  cases,  one  for  each  env.  event  */ 

/*  perform  synchronous  step  */ 
/*  env.  event  is  no  longer  needed  */ 
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Since  our  flight  guidance  system  is  a  synchronous  system,  it  falls  out  of  the  intended  scope  of  Spin. 
Nevertheless,  we  show  that  Spin  allows  us  to  successfully  carry  out  our  case  study.  The  Promela  fragment 
depicted  in  Table  5.1  encodes  our  synchronous  model  using  a  single  process,  namely  Spin’s  main  process 
init.  Here,  the  global  variable  env_ev  is  of  type  mtype,  which  contains  an  enumeration  of  all  event  and 
signal  names  that  may  occur  in  the  mode  logic.  Promela ’s  type  system  supports  basic  data  types  (such 
as  bit,  bool,  and  byte),  as  well  as  arrays ,  structures  (i.e.,  records),  and  channels.  Unfortunately,  it  only 
allows  a  single  declaration  of  an  enumeration  type ,  which  must  be  named  mtype.  The  statement  atomic 
in  init  attempts  to  execute  all  statements  in  its  body  in  one  indivisible  step.  Especially,  it  does  not  store 
intermediate  states  which  might  arise  during  the  execution  of  the  body.  Thus,  we  may  use  this  construct  for 
ehcoding  our  complex  algorithm  -  see  procedure  fgs  of  the  Mur^  model  in  Section  3  -  performing  a  single 
synchronous  step.  The  repetition  statement  do  together  with  the  nested  nondeterministic- choice  statement 
if  nondeterministically  chooses  which  environment  event  to  assign  to  variable  env„ev.  Since  env_ev  is 
no  longer  needed  outside  of  fgs  it  is  reset  to  dummy  value  null  and,  thus,  does  not  contribute  to  the 
observable  state  space.  The  reason  that  we  have  not  simply  spelled  out  fgs(vs_switch_hit),  and  so  on 
for  each  environment  variable,  is  that  -  as  we  argue  below  -  fgs  needs  to  be  implemented  as  an  inline . 
Expanding  this  long  inline  fourteen  times  turns  out  to  be  inefficient. 

Table  5.2 

Specification  of  module  simple  guidance  in  Spin 


inline 
{  if  : 


simple__guidance(mode,  event,  signal) 


mode==cleared  ->  if 


mode==active 


fi 
~>  if 


fi 


event-=activate  ->  signal=activated;  mode=active 
event==deactivate  ->  signal=null 

event==switch  ->  signal=activated;  mode=active 
event==clear  ->  signal=null 

e vent ==acti vat e  ->  signal=null 

event==deactivate  ->  signal=null;  mode= cleared 

event==switch  ->  signal=deactivated;  mode=cleared 
event==clear  ->  signal=deactivated;  mode=cleared 


fi  } 


Promela  does  not  possess  any  kind  of  procedure  construct  other  than  the  process  declaration  proctype. 
However,  we  may  not  introduce  additional  processes  to  the  main  process  init,  since  then  our  model  would 
not  reflect  a  synchronous  system  any  more.  The  only  construct  of  Promela,  which  we  can  use  for  resembling 
the  architecture  of  the  flight  guidance  system,  is  the  inline  construct  which  may  take  (call-by-reference)  pa¬ 
rameters,  such  as  the  parameters  mode,  event,  and  signal  for  component  simple-guidance  (cf.  Table  5.2). 
When  compiling  a  Promela  description,  each  occurrence  of  simple  ^guidance  in  vertical -guidance  is  re¬ 
placed  with  its  body.  The  modes  instantiating  the  parameter  mode  are  global  variables  of  type  bit,  where 
cleared  and  active  are  defined  to  represent  the  constants  0  and  1,  respectively,  using  the  preprocessor 
command  #def  ine.  The  events  and  signals  clear,  activate,  deactivate,  switch,  null,  activated,  and 
deactivated  are  of  type  mtype.  The  body  of  simple_guidance  contains  the  Promela  statement  if.  Its 
behavior  is  defined  by  a  nondeterministic  selection  of  one  of  its  executable  options,  which  are  separated 
by  double  colons,  and  by  executing  it.  In  our  case,  each  option  consists  of  a  guarded  expression,  which  is 
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executable  if  the  expression  on  the  left  of  ->  evaluates  to  true  in  the  current  system  state  under  consider¬ 
ation,  and  returns  the  result  of  evaluating  the  expression  on  the  right  hand  side.  As  in  the  programming 
language  C,  the  symbols  ==  and  =  stand  for  the  equality  operator  and  the  assignment  operator,  respectively. 
Using  the  Promela  description  of  simple_guidance,  we  can  specify  component  vertical-guidance  as  an¬ 
other  inline  parameterized  by  environment  event  env_ev  (cf.  Table  5.3).  The  body  of  vertical-guidance 
is  self-explanatory  and  similar  to  the  one  of  Mur</>.  It  should  only  be  noted  that  guard  else  is  always 
executable  and  that  expression  skip  leaves  the  current  system  state  unchanged.  Moreover,  the  Boolean 
functions  pitch_event,  vs.event,  and  vga.event  are  spelled  out  as  inlines  here. 

Table  5.3 

Specification  of  module  vertical  guidance  in  Spin 
bit  pitch_mode=cleared;  bit  vs_mode=cleared;  bit  vga_mode=cleared ; 

inline  pitch_event (env_ev)  {  env_ev==vs_pitch_vheel_changed  } 

inline  vs.event (env.ev)  {  env_ev==vs.switch_hit  } 

inline  vga.event (env.ev)  {  env_ev==ga.switch.hit  I!  env_ev==ap_engaged_event  II  ...  > 

inline  vertical.guidance (env.ev) 

{  if  : :  pitch.event (env.ev)  ->  . 

simple_gnidance (activate ,  pitch.mode,  pitch_signal) ; 

if  ::  pitch_signal==activated  ->  simple.guidance (deactivate,  vs.mode,  vs.signal); 

simple.guidance (deactivate,  vga_mode,  vga.signal) 

: :  else  ->  skip 

fi 

::  vs .event (env_ev)  -> 

simple_guidance( switch,  vs.mode,  vs.signal) ; 

if  ::  vs_signal==activated  ->  simple.guidance (deactivate,  pitch.mode,  pitch.signal) ; 

simple.guidance (deactivate,  vga.mode,  vga.signal) 

::  vs_signal==deactivated  ->  simple.guidance (  activate,  pit ch.mode,  pitch.signal) 

: :  else  ->  skip 

fi 

: :  vga.event (env.ev)  -> 

if  ::  env_ev==ga_switch.hit  ->  simple.guidance (switch,  vga.mode,  vga.signal) 

::  else  ->  simple.guidance (  clear,  vga.mode,  vga.signal) 

fi; 

if  ::  vga_signal==activated  ->  simple.guidance (deactivate,  pitch.mode,  pitch.signal); 

simple.guidance (deactivate,  vs.mode,  vs.signal) 

::  vga_signal==deactivated  ->  simple.guidance (  activate,  pitch.mode,  pitch.signal) 

: :  else  ->  skip 

fi 

: :  else  ->  skip 
fi  > 

The  verification  technique  we  employed  in  Spin  for  reasoning  about  the  flight  guidance  system,  namely 
assertions ,  is  similar  to  the  one  we  used  in  Mur </>.  More  precisely,  Promela ’s  assertion  statement  assert  aborts 
the  state  exploration  conducted  by  Spin’s  verifier  whenever  its  argument  expression  evaluates  to  false  in  some 
system  state  associated  with  the  assertion  statement.  Our  specification  of  the  mode  confusion  properties  are 
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Table  5.4 

Specification  of  some  mode  confusion  properties  in  Spin 


bit  old_pitch_mode=cleared;  bit  old_vs_mode=cleared;  bit  old_vga.mode=cleared; 


/*  check  for  response  to  pressing  VS  button  */ 

assert (! (old_vs_mode==cleared)  II  (vs_mode==active) ) ; 
assert (! (old_vs_mode==active  )  I  I  (vs_mode==cleared) ) ; 

/*  search  for  ignored  crew  inputs  (property  violated)  */ 
assert (! (crew.input)  | |  mode.change) ; 

/*  no  unknown  ignored  crew  inputs  */ 

assert (! (crew.input  &&  ! (ignored.crew.input) )  ||  mode.change); 

/*  search  for  indirect  mode  changes  (property  violated)  */ 
assert ( ! ( ! (crew.input) )  I  I  ! (mode. change) ) ; 

/*  no  unknown  indirect  mode  changes  */ 

assert (! (! (crew.input)  &&  ! ( indirect .mode. change ) )  |  |  ! (mode.change) ) ; 

/*  save  the  current  mode  values  */ 

old.pitch.mode=pitch.mode ;  old_vs.mode=vs_mode ;  old_vga.mode=vga_mode ; 


depicted  in  Table  5.4,  where  ‘ and  Ml’  stand  for  the  logical  connectives  not:  and ,  and  or,  respectively. 
Moreover,  the  symbols  /*  and  */  denote  the  begin  and  end  of  comments.  In  our  specification,  crew_input, 
mode^change,  ignored_crew_input,  and  indirect _mode_change,  which  are  defined  as  Boolean  functions  in 
Mur0,  are  simply  introduced  via  #def  ines.  In  order  to  encode  expression  mode_change,  we  have  to  keep  -  as 
in  the  Mur</>  model  -  a  copy  of  the  ‘old’  values  of  all  global  variables  of  interest.  Stating  the  mode  confusion 
properties  in  Spin’s  linear-time  logic  would  not  have  any  advantages  over  using  assertions.  The  reason  is 
that  Spin’s  version  of  linear-time  logic  does  not  include  the  next-state  operator ,  as  we  used  for  specifying 
these  properties  in  SMV.  This  is  because  many  verification  methods  employed  in  Spin,  such  as  partial  order 
techniques,  have  essentially  no  beneficial  effects  when  the  next-state  operator  is  present.  The  verification 
results  returned  by  the  Spin  verifier  are  similar  to  the  ones  for  Mur 0.  The  Spin  model  of  the  flight  guidance 
system  also  possesses  242  states  and  3388  transitions  (+  1  “dummy”  transition).  Unfortunately,  Spin  crashes 
and  core  dumps  when  analyzing  the  invalid  assertions  search  for  ignored  crew  inputs  and  search  for  indirect 
mode  changes.  However,  it  still  writes  an  error  trace  which  can  be  fed  into  Spin’s  simulator.  No  other  violated 
assertions  were  detected  during  the  exhaustive  state-space  search  which  took  under  2  seconds  and  required 
about  2.6  MBytes  memory  on  a  SUN  SPARCstation  20.  It  should  be  pointed  out  that  a  previous  effort  by  a 
NASA  contractor  to  analyze  a  variant  of  the  flight  guidance  system  using  Spin  was  unsuccessful  because  of 
an  intractably  large  state  space  [24].  Unfortunately,  from  the  report  it  is  not  clear  what  the  exact  causes  are. 
We  suspect  that  the  manner  in  which  the  model  was  constructed  is  one  of  the  main  causes  of  the  intractable 
state  space,  which  was  then  checked  for  invariant  properties  using  Spin’s  bitstate  hashing  algorithm  [17]. 

Summarizing,  the  modeling  and  verification  of  our  flight  guidance  system  was  feasible  in  Spin  but  less 
elegant  than  in  Mur<£.  This  is  mainly  because  of  the  lack  of  procedure  and  function  constructs  in  Promela, 
which  had  to  be  encoded  using  inlines  and  #def  ines.  However,  our  criticism  is  qualified  by  the  fact  that 
Spin  is  actually  not  intended  for  modeling  and  reasoning  about  synchronous  systems.  If  one  is  interested  in 
asynchronous,  concurrent  systems,  Spin  provides  the  process  declaration  proctype  as  a  means  for  encapsu¬ 
lating  system  components.  We  would  like  to  see  a  richer  type  system  in  Spin,  which  can  handle  more  than 
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one  mtype  definition.  Type  checking  is  a  powerful  tool  for  detecting  inconsistencies  and  saves  us  a  lot  of 
time  compared  to  checking  specifications  by  hand.  Also,  we  wish  for  the  next-state  operator  to  be  included 
in  Spin’s  linear-time  logic.  Similar  to  our  comments  for  Mur</>  we  remark  that  this  would  cut  the  size  of 
the  state  vector  and  Spin’s  memory  requirements  approximately  in  half.  Especially  useful  to  us  were  Spin’s 
capabilities  to  simulate  Promela  models  and  to  feed  back  error  traces  -  illustrating  the  cause  of  an  assertion’s 
invalidity  -  into  the  simulator.  Simulations  helped  us  to  identify  the  causes  of  ignored  crew  inputs  and 
indirect  mode  changes  in  a  very  time-efficient  manner.  Beside  the  feature  of  monitoring  variables,  we  found 
it  useful  that  Spin  highlights  the  part  of  the  Promela  description  corresponding  to  the  system  state  under 
investigation.  The  absence  of  rich  simulation  capabilities  in  Mur</>  and  SMV  makes  Spin  the  tool  of  choice 
for  discovering  design  flaws  interactively.  Finally,  Spin’s  nice  graphical  user  interface,  referred  to  as  Xspin, 
distinguishes  Spin  from  other  verification  tools. 

6.  Discussion  and  Related  Work.  In  this  section  we  discuss  the  most  important  strengths  and 
weaknesses  of  each  of  the  verification  tools  Mur 0,  SMV,  and  Spin  regarding  our  case  study.  We  structure 
our  discussion  by  separating  the  issues  related  to  the  tools’  (i)  system  description  languages,  (ii)  property 
description  languages,  and  (iii)  capabilities  for  system  simulation  and  for  animating  diagnostic  information. 

The  system  description  languages  of  all  three  verification  tools  allow  us  to  model  the  deterministic, 
synchronous  behavior  of  the  flight  guidance  system,  as  well  as  the  nondeterministic  behavior  of  the  system’s 
environment.  Especially,  Murk’s  system  description  language  proved  to  be  very  useful  for  the  following 
reasons.  First,  Mur</>  implements  numerous  language  constructs  and  a  rich  type  system,  as  found  in  many 
standard  high-level  imperative  programming  languages,  such  as  Pascal.  Second,  it  supports  a  modular 
programming  style  via  parameterized  procedures  and  functions.  Third,  it  allows  us  to  adapt  the  existing  PVS 
specification  of  the  mode  logic  in  a  straightforward  manner  [22].  One  major  difference  between  the  languages 
is  that  Mur</>  and  Spin  allow  model  encoding  using  a  sequential  algorithm,  whereas  SMV  requires  an  algorithm 
description  by  parallel  assignments.  As  a  consequence,  SMV  has  the  feel  of  a  low-level  or  hardware  description 
language.  However,  SMV’s  module  concept  is  slightly  more  elegant  than  Murk’s  procedure  concept  for  our 
application,  since  mode  variables  can  be  declared  within  the  module  to  which  they  belong  and  need  not 
be  declared  outside.  Regarding  Spin’s  system  description  language  Promela,  one  notices  that  it  is  actually 
designed  to  specify  asynchronous  systems,  especially  communication  protocols.  This  is  evident  by  the  fact 
that  it  only  offers  the  process  declaration  construct  proctype  for  encapsulating  code  fragments.  By  using 
inline  declarations  we  were  able  to  circumvent  this  problem  for  our  purposes.  Finally,  we  want  to  mention 
one  desired  feature  that  the  system  description  languages  of  all  three  tools  are  missing,  namely  the  ability  to 
organize  the  events  of  the  flight  guidance  system  in  a  taxonomy ,  e.g.,  by  including  subtyping  in  the  description 
languages.  The  presence  of  such  a  concept  would  help  us  to  naturally  divide  all  events  into  lateral-mode  and 
vertical-mode  events,  and  further  into  Pitch  events,  HDG  events,  etc.  This  taxonomy  was  encoded  in  Mur</> 
and  SMV  using  functions  and  in  Spin  using  inlines. 

Regarding  the  second  issue  concerning  the  property  description  languages  of  the  three  verification  tools, 
we  also  identified  several  important  differences.  We  first  note  that  all  of  the  mandatory  and  mode  confusion 
properties  of  interest  to  us  are  invariants.  Therefore,  they  can  be  stated  as  assertions  and  verified  in 
reachability  analysis  tools,  such  as  Mur <£,  as  well  as  more  general  model-checking  tools,  such  as  SMV  and 
Spin.  When  specifying  mode  confusion  properties,  SMV’s  adaptation  of  the  temporal  logic  CTL  is  most 
convenient,  not  because  of  its  expressiveness  which  we  hardly  use,  but  since  it  allows  one  to  implicitly  refer 
to  adjacent  states  in  program  paths  using  the  ‘next-state’  operator  AX.  This  is  important  for  describing 
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property  mode.change  which  requires  one  to  access  the  mode  variables  of  adjacent  states.  In  contrast  to 
Mur <f>  and  Spin,  the  encoding  of  mode  confusion  properties  in  SMV  does  not  require  the  storage  of  old 
values  of  mode  variables.  Thereby,  the  size  of  the  associated  state  vector  is  cut  in  half.  Unfortunately, 
the  ‘next-state’  operator  is  left  out  in  Spin’s  version  of  linear-time  logic.  Therefore,  we  could  employ  Spin 
only  as  an  assertion  checker,  similar  to  Mur </>.  In  addition  to  its  suitable  property  description  language, 
SMV’s  BDD-based  model  checker  performed  very  well  in  our  case  study.  Its  high  efficiency  is  due  to  the 
fact  that  mode  logics  have  the  characteristics  of  Boolean  terms  which  can  be  represented  in  a  very  compact 
way  using  BDDs.  However,  the  small  state  space  of  our  example  system  precludes  us  from  fairly  comparing 
the  run  times  of  the  Mur<^>,  SMV,  and  Spin  verifiers.  Finally,  we  remark  again  that  Mu r<p  and  Spin  compile 
system  and  property  descriptions  into  C++  and  C-code,  respectively,  which  may  be  considered  as  building 
special-purpose  verifiers.  This  compilation  process,  however,  is  considerably  slower  than  SMV’s  interpreter. 

Regarding  the  third  issue,  only  Spin  provides  rich  features  related  to  system  simulation  and  to  animation 
of  diagnostic  information.  System  simulation  is  especially  useful  when  being  combined  with  diagnostic 
information.  Each  tool  returns  an  error  trace  whenever  a  desired  system  property  is  invalidated  in  the 
model  under  consideration.  More  precisely,  Mur<f>  and  SMV  output  a  textual  description  of  an  error  trace, 
which  displays  the  global  variables’  assignments  at  all  states  of  this  trace,  and  allow  for  textual,  interactive 
simulations.  Spin,  however,  is  able  to  animate  error  traces  using  message  sequence  charts ,  time  sequence 
panels ,  and  data  value  panels  which  are  integrated  in  its  nice  graphical  user  interface ,  known  as  Xspin. 
In  our  case  study  dealing  with  a  synchronous,  single-process  system,  only  the  data  value  panel  was  of 
use.  However,  this  feature,  together  with  the  ability  to  highlight  the  source  code  line  corresponding  to  the 
current  state  in  the  simulation,  enabled  us  to  detect  sources  of  mode  confusion  in  a  very  time-efficient  manner 
compared  to  SMV  and  Mur <j>,  and  especially  when  compared  to  the  studies  of  failed  proof  subgoals  in  PVS. 

Finally,  related  work  other  than  the  PVS  case  study  regarding  the  flight  guidance  system  [5]  should  be 
mentioned.  The  CoRE  [9]  and  SCR  [14]  specifications  of  the  flight  guidance  system  [20,  21]  were  intended  for 
illustrating  the  utility  of  the  methods  for  specifying  new  generations  of  systems  in  a  more  rigorous,  consistent, 
and  structured  way.  Especially,  they  should  replace  the  traditional  custom  of  specifying  such  systems  in  plain 
English.  In  contrast  to  this  paper,  the  SCR  and  CoRE  specifications  were  not  subject  to  any  automated 
analysis  tools,  although  some  tool  support  for  them  exists  [14].  The  well-known  Z  specification  standard  [31] 
was  applied  to  the  flight  guidance  system  in  order  to  formally  express  concepts  that  appear  rather  informally 
in  CoRE  [10],  such  as  the  semantics  of  continuous  variables .  Recently,  tools  supporting  the  analysis  of  Z 
specifications  emerged,  e.g.,  Z/EVES  [27]  which  interfaces  Z  to  the  theorem  prover  EVES.  This  tool  was 
applied  to  the  Z  specification  of  the  flight  guidance  system  for  validating  some  of  the  mandatory  properties 
mentioned  also  in  this  paper,  as  well  as  for  proving  disjointness  and  completeness  of  table  entries  and  for 
determinism  checks.  The  gained  experiences  with  Z/EVES  are  very  similar  to  the  ones  made  with  PVS  [25]. 
ObjecTime  [28]  is  an  environment  for  testing  and  simulation  and  was  used  as  the  driving  engine  of  a  partial 
flight  deck  visualization  of  the  flight  guidance  system’s  behavior  [22]. 

7.  Conclusions  and  Future  Work.  This  paper  advocates  the  use  of  state-exploration  and  model¬ 
checking  techniques  for  analyzing  flight  guidance  systems  with  respect  to  causes  of  mode  confusion.  Com¬ 
pared  to  theorem  provers,  model-checking  tools  are  able  to  verify  invariants  automatically.  When  weighting 
the  strengths  of  the  verification  tools  Mur^,  SMV,  and  Spin  with  respect  to  our  application,  it  turned  out 
that  these  are  complementary.  Mur<^>  has  the  most  pleasant  system  description  language,  including  a  rich 
type  system  and  allows  for  high-level  specifications.  SMV’s  adaptation  of  the  temporal  logic  CTL  as  property 
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description  language  supports  the  convenient  specification  of  mode  confusion  properties.  Spin’s  capability  of 
animating  diagnostic  information,  which  is  returned  from  unsuccessful  verification  attempts,  is  very  useful. 
We  hope  that  our  experiences  might  give  tool  developers  some  useful  ideas  for  combining  the  strengths  of 
Mur<£,  SMV,  and  Spin  in  a  single  tool. 

Regarding  future  work,  our  case  study  should  be  extended  to  include  more  components  of  today’s  digital 
flight  decks  and  to  explore  other  interesting  properties  related  to  mode  confusion.  Also,  the  integration  of 
verification  tools  with  state-of-the-art  specification  languages,  such  as  UML  [28],  must  be  a  primary  goal  in 
order  to  make  formal  verification  techniques  accessible  to  engineers  in  industry  or  at  applied  research  labs. 

We  thank  Ricky  Butler  and  Steve  Miller  for  many  enlightening  discussions  about  mode  confusion,  as 
well  as  Ben  Di  Vito,  Michael  Mendler,  and  Cesar  Munoz  for  carefully  proofreading  a  draft  of  this  paper. 
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Appendix  A.  Specification  and  Verification  Using  Mur^. 

A.l.  Full  Model  of  the  Mode  Logic. 

TYPE  env_e vents  :  ENUM  {  hdg_switchjiit ,  nav_switch_hit , 

nav_armed_long_enough_event ,  nav_track_cond_met_event , 
ga_switch_hit ,  vs_pitch_wheel_changed , 

vs_switch_hit ,  fd_switch_hit , 

overspeed.start ,  overspeed_stop, 

ap_engaged_event ,  ap_disengaged_event , 

sync_svit  depressed,  sync_switch_released 

>; 

TYPE  sg.mode  :  ENUM  {  sg^cleared,  sg_active  }; 

TYPE  sg.signals  :  ENUM  {  sg_null,  sg.activated,  sg.deactivated  }; 

TYPE  sg.events  :  ENUM  {  sg_nil,  sg.activate,  sg.deactivate,  sg.switch,  sg_clear  }; 

TYPE  ag.mode  :  ENUM  {  ag.cleared,  ag.track,  ag_armed_initial,  ag_armed-long_enough  >; 

TYPE  ag.signals  :  ENUM  {  ag_null,  ag.activated,  ag.deactivated  }; 

TYPE  ag_events  :  ENUM  {  ag_nil,  ag.activate,  ag.deactivate ,  ag_switch,  ag.clear, 

ag_armed_long_enough_ev ,  ag_track_cond_met  }; 

TYPE  fd_mode  :  ENUM  {  fd_off,  fd_cues,  fd_no_cues  }; 

TYPE  fd.signals  :  ENUM  {  fd_null,  fd_turned_on,  fd_turned_off  }; 

TYPE  fd_events  :  ENUM  {  fd_nil,  fd_f orce.cues ,  fd_turn_on,  fd_switch,  fd_turn_off  }; 

TYPE  ag„state  :  RECORD  mode  :  ag_mode;  track_cond_met  :  boolean;  END; 

—  variables  controled  by  the  environment  - 

VAR  overspeed  :  boolean;  ap_engaged  :  boolean; 

—  mode  variables  - 

VAR  pitch,  old_pitch  :  sg_mode;  vs,  old_vs  :  sg.mode; 

roll,  old_roll  :  sg_mode;  hdg,  old_hdg  :  sg_mode; 

nav,  old_nav  :  ag.state;  fd,  old^fd  :  fd_mode; 

—  auxiliary  functions,  building  a  taxonomy  on  events  - 

FUNCTION  hdg_event (env_ev:env_events)  :  boolean; 

BEGIN 

IF  env_ev=hdg_switch_hit 
THEN  RETURN  true; 

ELSE  RETURN  false; 

END; 

END; 


vga,  old_vga  :  sg^mode; 
Iga,  old.lga  :  sg_mode; 
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FUNCTION  nav.event (env_ev:env_events)  :  boolean; 

BEGIN 

IF  (env_ev=nav_switch_hit)  |  (env_ev=nav_armed_long_enough_event)  | 

(env_ev=nav_track_cond_met_event) 

THEN  RETURN  true; 

ELSE  RETURN  false; 

END; 

END; 


FUNCTION  Iga.event (env_ev:env_e vents)  : -boolean; 

BEGIN 

IF  (env_ev=ga_switch_hit)  I  (env_ev=ap_engaged_event)  I  (env_ev=sync_switch_pressed) 
THEN  RETURN  true; 

ELSE  RETURN  false; 

END; 

END; 


FUNCTION  pitch.event (env_ev:env„events)  :  boolean; 
BEGIN 

IF  env_ev=vs_pitch_wheel_changed 
THEN  RETURN  true; 

ELSE  RETURN  false; 

END; 

END; 


FUNCTION  vs.event (env_ev:env_events)  :  boolean; 
BEGIN 

IF  env_ev=vs_switch_hit 
THEN  RETURN  true; 

ELSE  RETURN  false; 

END; 

END; 


FUNCTION  vga_event (env_ev: env_e vents)  :  boolean; 

BEGIN 

IF  (env_ev=ga_switch_hit)  |  (env_ev=ap_engaged_event)  |  (env_ev=sync_switch_pressed) 
THEN  RETURN  true; 

ELSE  RETURN  false; 

END; 

END; 
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FUNCTION  lateral_mode_requested(env_ev : env_e vents)  :  boolean; 

BEGIN 

IF  (env_ev=hdg_switch_hit)  |  (env_ev=nav_switch_hit)  |  (env_ev=ga_switch_hit) 

THEN  RETURN  true; 

ELSE  RETURN  false; 

END; 

END; 

FUNCTION  vertical_mode_requested(env_ev:env_events)  :  boolean; 

BEGIN 

IF  (env_ev=vs_switch_hit)  I  (env_ev=ga_switch__hit) 

THEN  RETURN  true ; 

ELSE  RETURN  false; 

END; 

END; 

FUNCTION  f light _director_event (env_ev:env_e vents)  :  boolean; 

BEGIN 

IF  (env_ev=ap_engaged__event)  |  (env_ev=fd_switch_hit)  |  (env_ev=overspeed_start)  | 
lateral_mode_requested(env„ev)  I  vertical_mode_requested(env_ev) 

THEN  RETURN  true; 

ELSE  RETURN  false; 

END ; 

END;  , 


—  abstract  data  type  module  simple  guidance  - 

simple_guidance(VAR  mode : sg^mode ;  event : sg_events ;  VAR  signal :sg_signals) ; 


IF  mode=sg_cleared  THEN 

SWITCH  event 

CASE  sg_nil 

signal 

:=  sg.null; 

CASE  sg.activate 

mode  :=  sg_active; 

signal 

:=  sg_ activated; 

CASE  sg.deactivate 

signal 

: =  sg.null; 

CASE  sg^switch 

mode  :=  sg_active; 

signal 

:=  sg_activated; 

CASE  sg_clear 

signal 

:=  sg_null; 

SWITCH 

event 

CASE 

sg_nil 

signal 

:  = 

sg.null ; 

CASE 

sg^activate 

signal 

:  = 

sg.null ; 

CASE 

sg_deactivate 

:  mode 

:=  sg.cleared;  signal 

:  = 

sg_null ; 

CASE 

sg_switch 

;  mode 

:=  sg^cleared;  signal 

:  = 

sg.deactivated 

CASE 

sg.clear 

;  mode 

:=  sg.cleared;  signal 

•  s 

sg_deactivated 
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—  abstract  data  object  module  arming  guidance 


PROCEDURE  arming_guidance  (event  :ag_events;  VAR  signal : ag.signals) ; 


IF  nav.mode=ag_cleared  THEN 
SWITCH  event 
CASE  ag_nil 
CASE  ag.activate 
CASE  ag_de activate 
CASE  ag.switch 
CASE  ag_clear 
CASE  ag_armed_long_enough_ 
CASE  ag_track_cond__met 
END; 


signal 

nav.mode  :=  ag_armed_initial;  signal 

signal 

nav.mode  :=  ag_armed_initial ;  signal 

signal 

signal 

nav.track_cond.jnet  :=  true;  signal 


:=  ag_null; 

:=  ag_activated; 
ag_null; 

: =  ag.activated; 
:=  ag_null; 

:=  ag.null; 

:=  ag_null; 


SWITCH  event 
CASE  ag_nil 
CASE  ag.activate 
CASE  ag.deactivate 
CASE  ag.switch 
CASE  ag.clear 
CASE  ag_armed_long_enough_ 


signal  :=  ag_null; 

signal  :=  ag_null; 

nav.mode  :=  ag_cleared;  signal  :=  ag.null; 

nav.mode  :=  ag_cleared;  signal  :=  ag_deactivated; 

nav.mode  :=  ag_cleared;  signal  ;»  ag_deactivated; 

IF  (nav.mode=ag_armed_initial)  &  nav . track_cond_met 


nav.mode  :=  ag.track;  signal  :=  ag_null; 

ELSIF  (nav.mode=ag_armed_initial)  &  !nav. track_cond_met 
THEN 

nav.mode  :=  ag_armed_long_enough;  signal  :=  ag.null; 
ELSE 

signal  :=  ag_null; 


CASE  ag_track_cond_met 


IF  nav . mode=ag_armed_long_enough  THEN 

nav.mode  :=  ag.track;  signal  ag.null; 

nav.track_cond_met  :=  true; 


nav . track_cond_met  : -  true ; 


signal  :=  ag.null; 


END;  END;  END; 


—  function  module  lateral  guidance  &  auxiliary  functions 

FUNCTION  hdg_conv(env_ev:env_e vents)  :  sg.events; 

BEGIN 

SWITCH  env_ev 

CASE  hdg_switch_hit  :  RETURN  sg.switch; 

ELSE  RETURN  sg.nil; 

END; 

END; 
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FUNCTION  nav_conv(env_ev:env_e vents)  :  ag_events; 

BEGIN 

SWITCH  env.ev 

CASE  nav_switch_hit  :  RETURN  ag_switch; 

CASE  nav_track_cond„met_event  :  RETURN  ag_track_cond_met ; 

CASE  nav_armed_long_enough..event  :  RETURN  ag_armed_long_enough_ev; 

ELSE  RETURN  ag_nil; 

END; 

END; 

FUNCTION  lga_conv(env__ev:env_events)  :  sg_events; 

BEGIN 

SWITCH  env.ev 

CASE  ga_switch_hit  :  RETURN  sg.activate; 

CASE  ap_engaged_event  :  RETURN  sg_clear; 

CASE  sync_switch_pressed  :  RETURN  sg.clear; 

ELSE  RETURN  sg_nil; 

END; 

END; 

PROCEDURE  lateral_guidance (env_ev : env_events) ; 

VAR  roll.sig,  hdg.sig,  lga.sig  :  sg_signals;  nav.sig  :  ag^signals; 

BEGIN  CLEAR  roll_sig;  CLEAR  hdg.sig;  CLEAR  lga_sig;  CLEAR  nav_sig; 

IF  hdg^event (env_ev)  THEN 

simple_guidance(hdg,  hdg_conv(env_ev) ,  hdg_sig) ; 

IF  hdg_sig=sg_ activated  THEN  simple_guidance(roll,  sg^deactivate,  roll.sig) 

simple  ..guidance  (lga,  sg_deactivate,  lga.sig  ) 
arming.guidance (  ag^deactivate,  nav_sig  ) 

ELSIF  h.dg_sig=sg_deactivated  THEN  simple_guidance (roll ,  sg_ activate,  roll.sig  ) 
END; 

ELSIF  nav_event (env_ev)  THEN 

arming_guidance (  nav_conv (env.ev) ,  nav_sig) ; 

IF  nav_sig=ag_activated  THEN  simple_guidance(roll ,  sg^de activate,  roll_sig) 

simple_guidance(hdg,  sg_deactivate,  hdg.sig  ) 
simple_guidance(lga,  sg_deactivate ,  Iga.sig  ) 
ELSIF  nav_sig=ag_de activated  THEN  simple_guidance (roll ,  sg.activate,  roll^sig  ) 
END; 

ELSIF  lga_event (env_ev)  THEN 

s imple_guidance ( lga ,  lga^conv (env^ev) ,  lga.sig) ; 

IF  lga_sig=sg_ activated  THEN  simple_guidance(roll,  sg.deactivate,  roll.sig) 

simple_guidance(hdg,  sg_de activate,  hdg.sig  ) 
arming_guidance (  ag_deactivate,  nav_sig  ) 

ELSIF  lga_sig=sg_deactivated  THEN  simple_guidance(roll,  sg.activate,  roll_sig  ) 
END; 

END; 

END; 
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—  function  module  vertical  guidance  &  auxiliary  functions - 

FUNCTION  pitch_conv(env_ev:env_events)  :  sg.events; 

BEGIN 

SWITCH  env_ev 

CASE  vs_pitch_wheel_changed  :  RETURN  sg„activate; 

ELSE  RETURN  sg_nil; 

END;  END; 

FUNCTION  vs_conv(env_ev:env_events)  :  sg_events; 

BEGIN 

SWITCH  env_ev 

CASE  vs_switch_hit  :  RETURN  sg.svitch; 

ELSE  RETURN  sg_nil; 

END;  END; 

FUNCTION  vga_conv(env_ev:env_events)  :  sg_events; 

BEGIN 

SWITCH  env_ev 

CASE  ga_switch_hit  :  RETURN  sg_switch; 

CASE  ap_engaged_event  :  RETURN  sg_clear; 

CASE  sync_svitch_pressed  :  RETURN  sg_clear; 

ELSE  RETURN  sg.nil; 

END;  END; 

PROCEDURE  vertical_guidance(env_ev:env_events) ; 

VAR  pitch_sig,  vs_sig,  vga_sig  :  sg_signals; 

BEGIN  CLEAR  pitch_sig;  CLEAR  vs_sig;  CLEAR  vga_sig; 

IF'pitch.event (env_ev)  THEN 

simple_guidance (pitch,  pitch_conv(env_ev) ,  pitch_sig) ; 

IF  pitch_sig=sg_activated  THEN  simple_guidance(vs,  sg.deactivate,  vs_sig  ); 

simple_guidance(vga,  sg.deactivate,  vga.sig  ); 

END; 

ELSIF  vs_event (env_ev)  THEN 

simple_guidance (vs ,  vs_conv(env_ev) ,  vs_sig) ; 

IF  vs_sig=sg_activated  THEN  simple_guidance  (pitch,  sg_deactivate,  pitch_sig) 

simple_guidance(vga,  sg_deactivate ,  vga_sig  ) 

ELSIF  vs_sig=sg_deactivated  THEN  simple_guidance  (pitch,  sg_activate,  pitch_sig  ) 
END; 

ELSIF  vga_event(env_ev)  THEN 

simple_guidance(vga,  vga_conv(env_ev) ,  vga_sig) ; 

IF  vga_sig=sg_activated  THEN  simple_guidance (pitch,  sg_deactivate ,  pitch_sig) 

simple__guidance(vs,  sg.deactivate,  vs_sig  ) 

ELSIF  vga_sig=sg_deactivated  THEN  simple_guidance (pitch,  sg_activate,  pitch_sig  ) 

END; 

END; 

END; 
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—  abstract  data  object  module  flight  director 


PROCEDURE  flight_director (event :fd_events;  VAR  signal : fd_signals) ; 
BEGIN 

IF  event=fd_nil  THEN  * 

signal  :=  fd_null; 

ELSIF  fd=fd_off  THEN 
SWITCH  event 


CASE 

fd_f orce_cues 

:  fd 

:=  fd.cues; 

signal 

:  =  fd_turned_on 

CASE 

fd_turn_on 

:  fd 

:=  fd.cues; 

signal 

:=  fd_turned_on 

CASE 

CASE 

END; 

fd_switch 

fd_turn_off 

:  fd 

:=  fd.cues; 

signal 

signal 

fd_turned_on 

:=  f d_null ; 

ELSIF  fd=fd_cues  THEN 


SWITCH  event 

CASE  fd_force_cues  :  signal  :=  fd.null; 

CASE  fd_turn_on  :  signal  :=  fd.null; 

CASE  fd_switch  :  IF  overspeed  |  ap_engaged  THEN 

fd  :=  fd_no_cues;  signal  :=  fd.null; 

ELSE 

fd  :=  fd_off;  signal  :=  f d_turned_of f ; 
END; 

CASE  fd_turn_off  :  IF  overspeed  I  ap.engaged  THEN 

fd  :=  f d_no_cues ;  signal  :=  fd_null; 

ELSE 

fd  :=  fd_off;  signal  :*=  f d_turned_of f ; 
END; 

END; 

ELSE 

SWITCH  event 

CASE  fd_f orce_cues  :  fd  :=  fd.cues;  signal  :=  fd.null; 

CASE  fd_turn_on  :  fd  :  =  fd.cues;  signal  :=  fd.null; 

CASE  fd_switch  *  :  IF  overspeed  |  ap_engaged  THEN 

fd  :=  fd_cues;  signal  :=  fd_null; 

ELSE 

fd  :=  fd_off;  signal  f d_turned_of f ; 
END; 

CASE  fd_turn_off  ;  IF  overspeed  |  ap_engaged  THEN 

signal  :=  fd_null; 

ELSE 

fd  :=  fd_off;  signal  :=  f d_turned_of f ; 
END; 

END; 

END; 

END; 
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—  mode  confusion  properties  as  assertions  &  auxiliary  functions 


FUNCTION  crew_input(env_ev:env_e vents)  :  boolean; 

BEGIN 

IF  (env_ev=ap_engaged_event)  *  |  (env_ev=sync_switch__pressed)  I 

(env_ev=sync_switch_released)  I  (env_ev=fd_switch_hit)  I 

lateral_mode_requested(env_ev)  |  vertical_mode_requested(env_ev)  I 

(env_ev=vs_pitch_wheel_changed) 

THEN  RETURN  true; 

ELSE  RETURN  false; 

END; 

END; 


FUNCTION  ignored_crew_input(env_ev:env_e vents)  :  boolean; 

BEGIN 

IF  ((env_ev=ap„engaged_event)  & 

! ( (old_lga=sg_active)  I  (old_vga=sg_active)))  I 
((env_ev=ga_switch_hit)  &  —  PVS  model  too  strong 

(old_lga=sg_active)  &  (old_vga=sg_active) )  |  —  (may  be  left  out) 

((env_ev=sync_switch_pressed)  & 

! ( (old_lga=sg_active)  |  (old_vga=sg_active) ) )  | 

( (env_ev=sync_switch_pressed)  &  —  PVS  model  too  strong 

(old_fd=fd_off ) )  |  —  (may  be  left  out) 

(env_ev=sync_switch_released)  I 

( (env_ev=vs_pitch_wheel_changed)  & 

(old_f d=f d_of f ) )  | 

( (env_ev=vs_pitch_wheel_changed)  & 

(old_pitch=sg_active) ) 

THEN  RETURN  true; 

ELSE  RETURN  false; 

END; 

END; 


FUNCTION  indirect_mode_change (env_ev: env_e vents)  :  boolean; 

BEGIN  ' 

IF  ( (env_ev=overspeed_start)  &  ! (old_fd=fd_cues)) 

( (env_ev=nav_armed_long_enough_event)  &  (old_nav.mode=ag_armed_initial  )) 
( (env_ev=nav_track_cond_met_event)  &  (old_nav .mode=ag_armed_long_enough) ) 
THEN  RETURN  true; 

ELSE  RETURN  false; 

END; 

END; 
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PROCEDURE  mode.confusion.properties(env.ev:env.events)  ; 

BEGIN 

ALIAS 

mode.change  :  fd  !=  old_fd  I  pitch  !=  old.pitch  I  vs  !=  old.vs  [  vga  !=  old_vga  I 
roll  !-  old.roll  I  hdg  !=  old.hdg  I  lga  !=  old.lga  I 
nav.mode  !=  old.nav.mode; 

DO 

SWITCH  env.ev 

CASE  hdg.switch.hit  : 

—  check  for  response  to  pressing  HDG  button 

assert  (old_hdg=sg_ cleared  ->  hdg  =sg.active)  "hdg.selected  and  hdg.toggle.l" ; 
assert  (old_hdg=sg_active  ->  roll=sg_active)  "hdg.deselected” ; 
assert  (old_hdg=sg_active  ->  hdg=sg_cleared)  ”hdg_toggle_2” ; 

CASE  nav.switch.hit  : 

—  check  for  response  to  pressing  NAV  button 

assert  (old_nav.mode=ag_cleared  ->  (nav.mode=ag_armed_ initial)  | 
(nav.mode=ag_armed_long_enough)  I  (nav.mode=ag_track) ) 

"nav.selected  and  nav.toggle.l" ; 

assert  (((old.nav.mode-ag.armed.initial)  I  (old_nav.mode=ag_armed_long.enough)  | 
(old_nav.mode=ag.track))  ->  roll=sg_active)  "nav.deselected" ; 

assert  ( ( (old_nav.mode=ag_armed_initial)  I  (old.nav.mode=ag_armed_long_enough)  I 
(old_nav.mode=ag_track))  ->  nav.mode=ag_cleared)  ”nav_toggle.2” ; 

CASE  vs.switch.hit  : 

—  check  for  response  to  pressing  VS  button 

assert  (old_vs=sg.cleared  ->  vs  =sg_active)  "vs.selected  and  vs.toggle.l” ; 
assert  (old.vs=sg_active  ->  pitch=sg_active)  ”vs_deselected" ; 
assert  (old.vs=sg_ active  ->  vs  =sg_cleared)  nvs_toggle_2”; 

CASE  fd_switch_hit  : 

—  check  for  response  to  pressing  the  FD  button  1 

assert  (old_fd=fd.off  ->  fd=fd_cues) 

"fd_off " ; 

assert  ( ( ! (old_fd=fd_off )  &  ! (ap_ engaged  I  overspeed))  ->  fd=fd_off)  "fd.on” ; 

assert  ( ((old_fd=fd_cues)  &  (ap.engaged  I  overspeed))  ->  fd=fd_no_cues)  "fd.cues"; 

assert  (((old.fd=fd.no.cues)  &  (ap.engaged  |  overspeed))  ->  fd=fd_cues)  "fd.no.cues" 

END; 

—  search  for  ignored  crew  inputs 

—  assert  (crew.input  (env.ev)  ->  mode.change)  ”search.for.ignored_crew_inputs" ; 

—  property  violated 

—  no  unknown  ignored  crew  inputs 

assert  ( (crew_ input (env_ev)  &  ! (ignored.crew. input (env_ev)))  ->  mode .change) 

"no .unknown. ignored. crew. inputs” ; 
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—  search  for  indirect  mode  changes 

—  assert  (! (crew.input (env.ev) )  ->  fmode.change)  "search.for.indirect.mode.changes" ; 

—  property  violated 

—  no  unknown  indirect  mode  changes 

assert  ((! (crew.input (env.ev) )  &  ! (indirect.mode.change (env.ev) ))  ->  Imode.change) 
"no.unknown.indirect.mode. changes ” ; 

END; 

—  update  old  state  variables 

old.pitch  ;=  pitch;  old_vs  :=  vs;  old_vga  :=  vga;  old_roll  :=  roll; 
old^hdg  :=  hdg;  old_lga  :=  lga;  old.fd  :=  fd;  old.nav  :=  nav; 

END; 


PROCEDURE  clear.all.modesO  ; 

BEGIN 

pitch  :=  sg_cleared;  vs 
hdg  :=  sg.cleared;  lga 
END; 

PROCEDURE  select .default. mode () ; 

BEGIN 

pitch  :=  sg_active;  roll  :=  sg.active; 

END; 

PROCEDURE  process.external.event (env_ev : env.events) ; 

BEGIN 

SWITCH  env.ev 

CASE  ap_engaged_event  :  ap.engaged  :*=  true; 

CASE  ap.disengaged.event  :  ap.engaged  :=  false; 

CASE  overspeed_ start  :  overspeed  :=  true; 

CASE  overspeed.stop  :  overspeed  :=  false; 

END; 

END; 

FUNCTION  fd.event (env.ev: env.events)  :  fd_events; 

BEGIN 

IF  env.ev=ap_engaged.event  THEN  RETURN  fd. turn-on; 

ELSIF  later al.mode.requested (env.ev)  THEN  RETURN  fd.turn.on; 
ELSIF  vertical.mode .requested (env.ev)  THEN  RETURN  fd_turn_on; 
ELSIF  env_ev=fd_switch_hit  THEN  RETURN  fd.switch; 

ELSIF  env.ev=overspeed.start  THEN  RETURN  fd.f orce.cues ; 

ELSE  RETURN  fd.nil; 

END; 

END; 


:=  sg.cleared;  vga  :=  sg.cleared;  roll  :=  sg.cleared; 

:=  sg.cleared;  nav. mode  :=  ag.cleared; 
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PROCEDURE  process_fd_event (env.ev: env.events) ; 

VAR  fd.sig  :  fd.signals; 

BEGIN 

IF  flight. director .event (env.ev)  THEN 

f light .director (fd.event (env.ev) ,fd_sig) ; 

IF  fd_sig=fd_turned.off  THEN  clear.all.modes () ; 

ELSIF  fd_sig=fd.turned_on  THEN  select.def  ault.modeQ  ; 

END; 

END; 

END; 

PROCEDURE  process.flight.mode.event (env_ev:env_events) ; 

BEGIN 

IF  ! (fd=fd_off )  THEN  lateral.guidance(env.ev) ;  vert i cal .guidance (env.ev) ;  END; 
END; 

PROCEDURE  f gs (env.ev : env.events) ; 

BEGIN 

process.external.event  (env.ev)  ;  process.f  d.event  (env.ev) ; 

process.flight.mode.event  (env.ev)  ;  mode.conf usion.properties  (env.ev)  ; 

END; 

—  model  of  the  environment  using  rules - 


RULE  "hdg.switch.hit" 

BEGIN  fgs (hdg.switch.hit) ; 

END 

RULE  "nav.switch.hit" 

BEGIN  fgs (nav.switch.hit) ; 

END 

RULE  "nav.armed.long.enough.event " 

BEGIN  fgs (nav.armed.long.enough.event) ; 

END 

RULE  "nav.track_cond_met_event" 

BEGIN  fgs (nav.track.cond.met. event) ; 

END 

RULE  "ga.switch.hit" 

BEGIN  fgs (ga.switch.hit) ; 

END 

RULE  "vs.pitch.wheel.changed" 

BEGIN' fgs (vs.pitch.wheel.changed) ; 

END 

RULE  "vs.switch.hit" 

BEGIN  fgs (vs.switch.hit) ; 

END 

RULE  "fd.switch.hit" 

BEGIN  fgs (fd.switch.hit) ; 

END; 

RULE  "overspeed.start" 

BEGIN  fgs (overspeed.start) ; 

END: 

RULE  "overspeed.stop" 

BEGIN  fgs (overspeed.stop) ; 

END: 

RULE  "ap.engaged.event" 

BEGIN  fgs (ap.engaged.event) ; 

END: 

RULE  "ap.disengaged.event" 

BEGIN  fgs (ap.disengaged.event) ; 

END; 

RULE  "sync.switch.pressed" 

BEGIN  fgs(sync.switch.pressed) ; 

END; 

RULE  "sync.switch.released" 

BEGIN  fgs(sync.switch.released) ; 

END; 

—  start  state  - 

STARTSTATE 

BEGIN 

overspeed  :=  false;  ap.engaged  false; 

CLEAR  pitch;  CLEAR  vs;  CLEAR  vga;  CLEAR  roll;  CLEAR  hdg;  CLEAR  lga; 
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CLEAR  nav.mode;  nav.track_cond_met  :=  false; 


CLEAR  fd; 


CLEAR  old.pitch;  CLEAR  old_vs;  CLEAR  old. vga;  CLEAR  old.roll;  CLEAR  old.hdg; 

CLEAR  old.lga;  CLEAR  old_nav.mode ;  old_nav.track_cond_met  :=  false;  CLEAR  old_fd; 

END; 

—  mandatory  properties  as  invariants  - 

ALIAS 

nav.active  :  (nav.mode=ag_armed.initial)  |  (nav.mode=ag_armed_long_enough)  I 
(nav.mode=ag_track) ; 

DO 

—  the  flight  director  is  on  if  the  autopilot  is  engaged 

INVARIANT  "fd.on.if.ap.engaged" 
ap.engaged  ->  \ (fd=fd_off ) ; 

—  at  least  one  lateral  mode  is  active  iff  the  flight  director  is  on 

INVARIANT  "at.least.one.lateral.mode.active" 

( !  (f d=fd_off )  ->  (roll=sg_active  |  hdg=sg_active  |  lga=sg_active  |  nav_active))  & 

( (roll=sg„active  |  hdg=sg_active  I  lga=sg_active  I  nav.active  )  ->  ! (fd=fd_off ) ) ; 

—  there  is  never  more  than  one  lateral  mode  active 

INVARIANT  ’'at.most.one.lateral.mode.active" 

((lga=sg_ active)  ->  (roll=sg_cleared  &  hdg=sg_cleared  &  nav.mode=ag_cleared) )  & 

( (roll=sg_active)  ->  (lga  =sg_cleared  &  hdg=sg_cleared  &  nav.mode=ag_cleared) )  & 

((hdg=sg. active)  ->  (roll=sg_cleared  &  lga=sg.cleared  &  nav.mode=ag_ cleared) )  & 

(nav.active  ->  (roll=sg_cleared  &  hdg=sg.cleared  &  lga=sg_cleared)) ; 

—  at  least  one  vertical  mode  is  active  iff  the  flight  director  is  on 

INVARIANT  "at.least.one.vertical.mode.active" 

( !  (fd=fd.off )  ->  (vga=sg_active  I  vs=sg_active  I  pitch=sg.active) )  & 

((vga=sg_active  |  vs=sg. active  |  pitch=sg_active)  ->  ! (fd=fd.off ) ) ; 

—  at  most  one  vertical  mode  is  active 

INVARIANT  "at.most.one.vertical.mode.active" 

(vga  =sg_active  ->  (pitch=sg_cleared  &  vs  =sg_cleared) )  & 

(vs  =sg.active  ->  (pitch=sg_cleared  &  vga=sg_cleared) )  & 

(pitch=sg_active  ->  (vga  =sg_cleared  &  vs  =sg_cleared) ) ; 
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—  if  the  flight  director  is  off,  all  modes  must  be  cleared 


INVARIANT  "fd_off_implies_all_modes_cleared" 

(fd=fd_off  ->  (pitch=sg_cleared  &  vs=sg_cleared  &  vga=sg_cleared  & 

roll  =sg_cleared  &  hdg=sg_cleared  &  lga=sg_cleared  &  nav.mode=ag_cleared) 


); 


—  the  default  modes  are  active  if  the  flight  director  is  on  and  all  other  modes  are  cleared 
INVARIANT  "default .modes'1 

(( ! (fd=fd_off)  &  vs=sg_cleared  &  vga=sg_cleared  &  hdg=sg_ cleared  & 
lga=sg_cleared  &  nav.mode=ag_cleared 
)  ->  (pitch=sg_active  &  roll=sg_active) ) ; 

END; 


A. 2.  Output  of  the  Mur</>  verifier. 

This  program  should  be  regarded  as  a  DEBUGGING  aid,  not  as  a 
certifier  of  correctness. 

Call  with  the  -*1  flag  or  read  the  license  file  for  terms 
and  conditions  of  use. 

Run  this  program  with  "-h"  for  the  list  of  options. 

Bugs,  questions,  and  comments  should  be  directed  to 
"murphi® verify . Stanford . edu" . 

Murphi  compiler  last  modified  date:  Jan  29  1999 
Include  files  last  modified  date:  Jan  29  1999 


Murphi  Release  3.1 

Finite-state  Concurrent  System  Verifier. 

Copyright  (C)  1992  -  1999  by  the  Board  of  Trustees  of 
Leland  Stanford  Junior  University. 


Protocol:  fgs 
Algorithm: 

Verification  by  breadth  first  search. 

with  symmetry  algorithm  3  —  Heuristic  Small  Memory  Normalization 
with  permutation  trial  limit  10. 
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Memory  usage: 


*  The  size  of  each  state  is  160  bits  (rounded  up  to  20  bytes) . 

*  The  memory  allocated  for  the  hash  table  and  state  queue  is 
8  Mbytes. 

With  two  words  of  overhead  per  state,  the  maximum  size  of 
the  state  space  is  327869  states. 

*  Use  option  M-k"  or  "-m"  to  increase  this,  if  necessary. 

*  Capacity  in  queue  for  breadth-first  search:  32786  states. 

*  Change  the  constant  gPercentActiveStates  in  mu_prolog. inc 
to  increase  this,  if  necessary. 

Warning:  No  trace  will  not  be  printed  in  the  case  of  protocol  errors! 
Check  the  options  if  you  want  to  have  error  traces. 


Status : 

No  error  found. 

State  Space  Explored: 

242  states,  3388  rules  fired  in  1.80s. 

Rules  Information: 


Fired 

242 

times 

- 

Rule 

"sync_switch_released" 

Fired 

242 

times 

- 

Rule 

"sync_switch_pressedM 

Fired 

242 

times 

- 

Rule 

" ap_disengaged_event " 

Fired 

242 

times 

- 

Rule 

" ap_engaged_event " 

Fired 

242 

times 

- 

Rule 

Moverspeed_stop" 

Fired 

242 

times 

- 

Rule 

"overspeed_ start" 

Fired 

242 

times 

- 

Rule 

"fd_switch_hit" 

Fired 

242 

times 

- 

Rule 

" vs_swit ch_hit " 

Fired 

242 

times 

- 

Rule 

"vs_pitch_wheel_changed" 

Fired 

242 

times 

- 

Rule 

"ga.switchjiit" 

Fired 

242 

times 

- 

Rule 

"nav_track_cond_met_eventH 

Fired 

242 

times 

- 

Rule 

"nav_armed_long_enough_event 

Fired 

242 

times 

- 

Rule 

"nav_switch_hit" 

Fired 

242 

times 

- 

Rule 

"hdg_switch_hit" 
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Appendix  B.  Specification  and  Verification  Using  SMV. 

B.l.  Full  Model  of  the  Mode  Logic. 

MODULE  simple.guidance (activate,  deactivate,  switch,  clear,  fd.is.on) 

VAR 

mode  :  {cleared,  active}; 


ASSIGN 

init(mode) 
next (mode) 


cleared; 

case 

! fd.is.on 

deactivated  1  deactivate 
activated 
1 

esac ; 


mode; 

cleared; 

active; 

mode; 


DEFINE 

activated  :=  (mode= cleared)  &  (activate  I  switch); 
deactivated  :=  (mode=active  )  &  (clear  I  switch); 


MODULE  arming.gui dance (activate,  deactivate,  switch,  clear,  track.cond.met.event , 
armed.long.enough.event ,  fd.is.on) 

VAR 

mode  :  {cleared,  track,  armed. initial,  armed. long.enough } ; 

track.cond.met  :  boolean; 

ASSIGN 

init (track.cond.met)  :=  0; 

next (track.cond.met)  :=  track.cond.met  |  track.cond.met.event ; 

init (mode)  :=  cleared; 
next (mode)  :=  case 

!fd_is_on 

deactivated  I  deactivate 
(mode=armed_long_enough)  &  track.cond 
(mode=armed_initial)  &  track.cond  & 
armed. long.enough.e vent 
activated 

(mode=armed_initial)  &  ! track.cond  & 
armed.long.enough.event 

1 

esac; 


mode; 

cleared; 

track; 

track ; 

armed. initial; 

armed. long. enough ; 
mode; 


33 


DEFINE 


track.cond  :=  track. cond.met  |  track_cond_met_event ; 

mode_armed  :=  (mode=armed_initial)  |  (mode=armed_long_enough) ; 
mode.active  :=  (mode_armed)  I  (mode=track) ; 

activated  :=  (mode=cleared)  &  (activate  I  switch); 
deactivated  :=  mode.active  &  (clear  |  switch); 


MODULE  lateral_guidance(_hdg_switch_hit ,  _ga_switch_hit ,  _ ap_ engaged. event , 

.sync.switch.pressed,  _nav.switch.hit,  .nav.armed.long.enough.event , 
.nav.track.cond.met.event ,  clear,  select.def atilt ,  f d.is.on) 

VAR 

roll  :  simple_guidance(roll_activate,  roll.deactivate, 

roll. switch,  roll.clear  ,  f d.is.on) ; 

hdg  :  simple.guidance(hdg_activate,  hdg.deactivate, 

hdg.switch,  hdg.clear  ,  f d.is.on) ; 

ga  :  simple_guidance(ga.activate,  ga.deactivate, 

ga.switch,  ga.clear  ,  f d.is.on) ; 

nav  :  arming.guidance (nav.activate ,  nav.deactivate, 

nav.switch,  nav.clear, 

nav.track.cond.met ,  nav.armed.long.enough ,  f d.is.on) ; 

DEFINE 

roll.activate  :=  (hdg.event  &  hdg. deactivated)  |  (nav.event  &  nav. deactivated)  | 

(lga.event  &  ga. deactivated  )  |  select.def ault ; 
roll.deactivate  :=  (hdg.event  &  hdg. activated)  |  (nav.event  &  nav. activated)  | 

(lga.event  &  ga. activated  ); 
roll.switch  :=  0; 

roll.clear  :=  (clear  &  ! select.def ault) ; 

hdg.activate  :=  0; 

hdg.deactivate  :=  (nav.event  &  nav. activated)  |  (lga.event  &  ga. activated  ); 

hdg.switch  :=  _hdg.switch.hit; 

hdg.clear  :=  clear; 

ga.activate  : =  _ga.switch.hit ; 

ga.deactivate  :=  (hdg.event  &  hdg. activated)  |  (nav.event  &  nav. activated)  ; 

ga.switch  :=  0; 

ga.clear  :=  .ap.engaged.event  I  .sync.switch.pressed  |  clear; 

nav.activate  :=  0; 

nav.deactivate  :=  (hdg.event  &  hdg. activated)  I  (lga.event  &  ga. activated  ); 

nav.switch  :=  _nav.switch.hit ; 


nav_clear 

nav_track_cond_met 

nav.armed.long.enough 


=  hdg. activated  I  ga. activated  |  clear; 
=  .nav.track.cond.met.event; 

=  .nav.armed.long.enough.event ; 


hdg.event 

lga_event 

nav.event 


=  _hdg.switch.hit; 

=  _ga.switch.hit  |  .ap.engaged.event  I  .sync.switch.pressed; 
=  _nav_switch_hit  I  .nav.armed.long.enough.event  I 
.nav.track.cond.met.event ; 


MODULE  vertical_guidance(_vs_pitch_wheel_changed,  _vs.switch.hit,  _ga.switch.hit, 

.ap.engaged.event ,  .sync.switch.pressed , 

clear,  select.def ault ,  fd.is.on) 


VAR 

pitch  : 

vs  : 

ga  : 


simple.guidance (pitch.activate , 
pitch.switch, 

simple .guidance (vs.activate , 
vs. switch, 

simple.guidance (ga.activate , 
ga.switch. 


pitch.deactivate , 
pitch.clear,  fd.is.on); 

vs.deactivate, 

vs.clear,  fd_is_on) ; 

ga_ deactivate , 

ga.clear,  fd.is.on) ; 


DEFINE 


pitch.activate  :=  (vs.event  &  vs . deactivated)  I  (vga.event  &  ga. deactivated)  I 
.vs.pitch.wheel.changed  I 

select _def ault ; 

pitch.deactivate  :=  (vs.event  &  vs . activated)  |  (vga.event  &  ga. activated) ; 
pitch.switch  :=  0; 

pitch.clear  :=  (clear  &  ! select.def ault) ; 


vs.activate 

vs.deactivate 

vs.switch 

vs.clear 


=  0; 

=  (pitch.event  &  pitch. activated)  I  (vga.event  &  ga. activated 
=  _vs_switch_hit; 

=  clear; 


ga_ activate 
ga.deactivate 
ga.switch 
ga.clear 


=  0; 

=  (pitch.event  &  pitch. activated)  1  (vs.event  &  vs. activated  ); 
=  _ga.switch.hit; 

=  -ap.engaged.event  I  .sync.switch.pressed  I  clear; 


pitch.event 
vs. event 
vga.event 


=  .vs.pitch.wheel.changed; 

=  _vs.switch.hit; 

=  _ga.switch.hit  1  .ap.engaged.event  I  .sync.switch.pressed; 
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MODULE  flight, 

VAR 

mode  :  {off 

ASSIGN 

init(mode)  : 
next (mode)  : 


DEFINE 
mode. on 
turned. on 
turned.off 


MODULE  main 

VAR 

env.ev 


overspeed  : 
ap_ engaged  : 

fd  : 

lateral  *  : 


.director (force.cues ,  turn.on,  switch,  turn.off, 
.ap.engaged,  .overspeed) 


cues,  no.cues}; 


=  off ; 

=  case 

turned.off 
turned. on 
(mode=no_cues)  & 

(force.cues  I  turn.on  |  (switch  &  (.overspeed  |  .ap.engaged) ) ) 
(mode=cues)  &  switch  &  (.overspeed  |  .ap.engaged) 

1 

esac; 


=  (mode=cues)  |  (mode=no_cues) ; 

=  (mode=off )  &  (turn.on  |  force.cues  |  switch) ; 

=  (mode.on)  &  (switch  |  turn.off)  &  !_overspeed  &  ! .ap.engaged; 


{hdg.switch.hit , 
nav.armed.long.enough.event , 
ga.switch.hit , 
vs.switch.hit, 
overspeed.staxt , 
ap.engaged.event , 
sync.switch.pressed , 

boolean; 

boolean; 

f light.director (f d.f orce.cues , 
fd. turn. off. 


nav.switch.hit , 
nav_track.cond.met. event , 
vs.pitch.wheel.changed , 
fd.switch.hit, 
o ver speed.end , 
ap.disengaged.event , 
sync.switch.released  }; 


fd.turn.on,  fd.switch, 
fd. ap.engaged,  fd.overspeed) ; 


lateral.guidance ( lg.hdg.swit ch.hit ,  lg.ga.swit ch.hit , 

lg_ ap.engaged,  lg.sync.switch.pressed, 

lg.nav.s wit  ch.hit ,  lg.nav.armed.long.enough , 
lg_nav.track_cond.met , 
lg_cle£Lr,  lg.select.default ,  r 

fd.is.on) ; 


:  off; 

:  cues ; 

:  cues ; 

:  no.cues; 
:  mode; 
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vertical  :  vert ical .guidance (vg_vs_pitch_wheel_changed,  vg_vs_switch_hit , 

vg_ga_switch_hit ,  vg.ap.engaged , 

vg_sync_switch„pressed , 

vg_clear,  vg_select_def ault , 

fd_is_on) ; 

ASSIGN 

init(env_ev)  :=  all.events; 

next(env.ev)  :=  all.events; 

init  (overspeed)  :=  0; 

next  (overspeed)  :=  new.overspeed; 

init(ap_engaged)  :=  0; 

next(ap.engaged)  :=  new_ap_engaged ; 

DEFINE 

all_events  :=  {hdg.switch.hit ,  nav.switchjiit , 

nav_armed_long_enough_event ,  nav_track_cond_met .event , 
ga.switch.hit ,  vs_pitch_wheel_changed, 

vs.switch.hit ,  fd.switch.hit , 

overspeed_start ,  overspeed.end, 

ap.engaged.event ,  ap.disengaged.event , 

sync.switch.pressed,  sync.switch.released  }; 

new.overspeed  :=  case 

(env_ev=overspeed_start) 

( env_e v-o ver speed_end) 

1 

esac; 

new.ap.engaged  :=  case 

(env_ev=ap_engaged_event)  :  1; 
(env_ev=ap_disengaged_event)  :  0; 

1  :  ap.engaged; 

esac; 

fd_is_on  :=  ! (fd.mode=off )  |  fd. turned.on; 

lateral_mode_requested  :=  (env_ev=hdg_switch_hit)  |  (env„ev=nav_switch_hit)  | 

(env_ev=ga_switch_hit) ; 

vertical.mode.requested  :=  (env_ev=vs_switch_hit)  I  (env_ev=ga_switch_hit) ; 

flight .director .event  :=  (env_ev=ap_engaged_event)  I  (env_ev=fd_switchjiit)  I 

(env_ev=overspeed_start)  I 

lateral_mode_requested  I  vertical_mode_requested; 


l; 

0; 

over speed; 
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fd.force.cues 

fd_turn_on 

fd.switch 

fd_turn_off 

fd.ap.engaged 

fd.overspeed 

lg.hdg.switch.hit 

lg_ga_switch_hit 

lg_ap_engaged 

lg-sync.switch.pressed 

lg.nav.switch.hit 

lg_nav_armed_long.enough 

lg.nav_track_cond.met 

lg_clear 

lg_select_default 

vg_vs_pitch_wheel_changed 

vg.vs.switch.hit 

vg_ga_switch_hit 

vg_ap_engaged 

vg_sync_switch_pressed 

vg_clear 

vg.select .default 
—  mandatory  properties  - 


:=  (env_ev=overspeed_start) ; 

(env_ev=ap_engaged_event)  | 

lateral .mode.requested  |  vertical_mode_requested; 
:=  (env_ev=fd_switch_hit) ; 

:=  0; 

:=  new.ap.engaged ; 

:=  new_overspeed; 

=  (env_ev=hdg_switch_hit) ; 

=  (env_ev=ga_switch_hit) ; 

=  (env_ev=ap_engaged_event) ; 

=  (env.ev^sync.switch.pressed) ; 

-  (env_ev=nav_switch_hit) ; 

=  (env_ev=nav_armed_long_enough_event) ; 

=  (env_ev=nav_track_cond_met_event) ; 

=  f light .director.event  &  fd.turned.off ; 

=  flight_director_event  &  fd.turned.on; 

=  (env_ev=vs_pitch_wheel_changed) ; 

=  (env_ev=vs_switch_hit) ; 

=  (env_ev=ga_switch_hit) ; 

==  (env_ev=ap_engaged_event)  ; 

=  (env_ev=sync_switch_pressed) ; 

=  flight_director_event  &  fd.turned.off; 

=  f light.director.event  &  fd. turned_on; 


—  the  flight  director  is  on  if  the  autopilot  is  engaged 
DEFINE  fd_on_if_ap_engaged  :=  AG  (ap.engaged  ->  ! (fd.mode=off ) ) ; 
SPEC  fd_on_ if _ap_ engaged 


—  at  least  one  lateral  mode  is  active  iff  the  flight  director  is  on 


DEFINE  at _least_one_ lateral .mode .active  := 

AG  (! (fd.mode=off )  <->  (lateral. roll. mode=active 

lateral . ga . mode=active 


); 


I  lateral. hdg. mode=act ive  '  I 
I  lateral.nav.mode.active  ) 


SPEC  at.least.one.lateral.mode.active 
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—  there  is  never  more  than  one  lateral  mode  active 

DEFINE  at_most_one„lateral_mode_active  :  = 

AG ( (lateral ,ga.mode=active  ->  (lateral. roll. mode^cleared  &  lateral .hdg.mode=cleared  & 

lateral. nav.mode=cleared  ) 

)  & 

(lateral .roll .mode=active  ->  (lateral .ga.mode=cleared  &  lateral .hdg.mode=cleared  & 

lateral .nav.mode=cleared  ) 

)  & 

( later al.hdg.mode=active  ->  (lateral. roll. mode=cleared  &  lateral. nav.mode=cleared  & 

later al.ga.mode=cleared  ) 

)  & 

(lateral .nav.mode_active  ->  (lateral. roll. mode=cleared  &  lateral.hdg.mode=cleared  & 

lateral .ga.mode=cleared  ) 

) 

> ; 

SPEC  at_most_one_lateral_mode_active 

—  at  least  one  vertical  mode  is  active  iff  the  flight  director  is  on 


DEFINE  at_least_one_vertical_mode_active  := 

AG  ( ! (fd.mode=off )  <->  (vertical .ga.mode=active  I  vertical. vs. mode=active  I 

vertical. pitch. mode=active  ) 

); 


SPEC  at_least_one_vertical.jnode_active 
—  at  most  one  vertical  mode  is  active 


DEFINE  at„most_one_vertical_mode_active  := 

AG  (( vertical. ga.mode=active  ->  (vertical .pitch. mode=cleared  &  vertical. vs .mode=cleared) )  & 
(vertical. vs. mode=active  ->  (vertical. pitch. mode=cleared  &  vertical .ga.mode=cleared) )  & 
(vert ical. pitch. mode=active  ->  (vertical .ga.mode=cleared  &  vertical. vs .mode=cleared)) 

); 

SPEC  at_most_one_vertical_mode_active 


—  if  the  flight  director  is  off,  all  modes  must  be  cleared 


DEFINE  fd^off.implies.all.modes.cleared  := 

AG  (fd.mode=off  ->  (vert ical. pit ch.mode=cleared  &  vertical. vs. mode 
vert ical.ga. mode  =cleared  &  lateral. roll .mode 

lateral .hdg. mode  =cleared  &  lateral . ga. mode 

lateral.nav.mode  =cleared 

) 

); 


= cleared  & 
=cleared  & 
=cleared  & 
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SPEC  fd_off_implies_all_modes_cleared 

—  the  default  modes  are  active  if  the  flight  director  is  on  and  all  other  modes  are  cleared 
DEFINE  def ault .modes  := 

AG  ((! (fd.mode=off )  &  vertical. vs .mode  =cleared  &  vertical .ga. mode  =cleared  & 
lateral.hdg.mode  =cleared  &  later al.ga. mode  =cleared  & 
lateral . nav . mode  =cleared 

)  -> 

(vertical. pit ch.mode=active  &  lateral .roll .mode=active) 

); 

SPEC  default .modes 

—  mode  confusion  properties  - 

—  check  for  response  to  pressing  HDG  button 
DEFINE 

hdg.selected.and.hdg.toggle.l  := 

AG  (lateral. hdg. mode=cleared  &  env_ev=hdg_switch_hit  ->  AX  lateral .hdg. mode=active) ; 
hdg_ deselected  := 

AG  (lateral.hdg.mode=active  &  env_ev=hdg_switch_hit  ->  AX  lateral  .roll  .mode=active) ; 
hdg_toggle_2  := 

AG  (lateral. hdg. mode=active  &  env_ev=hdg_switch_hit  ->  AX  lateral. hdg. mode=cleared) ; 

SPEC  hdg_selected_and_hdg_toggle.l 
SPEC  hdg.deselected 
SPEC  hdg_toggle_2 

—  check  for  response  to  pressing  NAV  button 
DEFINE 

nav_selected_and_nav_t oggle. 1  :  = 

AG  (lateral. nav. mode^cleared  &  env_ev=nav_switch_hit  ->  AX  lateral .nav. mode.active) ; 
nav.deselected  := 

AG  (lateral. nav. mode.active  &  env_ev=nav.switch.hit  ->  AX  lateral. roll. mode=act ive) ; 
nav_toggle_2  := 

AG  (lateral. nav. mode=active  &  env_ev=nav_switch_hit  ->  AX  lateral  .nav. mode=cleared)  ; 

SPEC  nav_selected_and_nav_toggle_l 
SPEC  nav.deselected 
SPEC  nav_toggle_2 
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—  check  for  response  to  pressing  VS  button 
DEFINE 

vs.selected.and.vs.toggle.i  := 

AG  (vertical .vs .mode^cleared  &  env_ev=vs.switch_hit  ->  AX  vertical. vs .mode=active) ; 
vs.deselected  := 

AG  (vertical. vs .mode=active  k  env_ev=vs_switch_hit  ->  AX  vertical .pitch. mode=active) ; 
vs_toggle.2  := 

AG  (vertical. vs. mode=active  &  env.ev=vs_switch.hit  ->  AX  vertical. vs. mode=cleared) ; 

SPEC  vs.selected.and.vs.toggle.i 
SPEC  vs.deselected 
SPEC  vs_toggle_2 

—  check  for  response  to  pressing  the  FD  button 
DEFINE 

fd_off  :=  AG  (fd.mode=off  k  env_ev=fd.switch_hit  ->  AX  fd.mode=cues) ; 

fd.on  :=  AG  ( ! (fd.mode=off )  k  env_ev=fd.switch_hit  & 

! (ap_engaged  I  overspeed)  -> 

AX  fd.mode=off 

); 

fd_cues  :=  AG  (fd.mode=cues  k  env_ev=fd_switch_hit  k 

(ap.engaged  |  overspeed)  -> 

AX  fd.mode=no_cues 

); 

fd.no.cues  AG  (fd.mode=no_cues  k  env.ev^fd.switch.hit  k 
(ap_engaged  |  overspeed)  -> 

AX  fd.mode=cues 

); 

SPEC  fd.off 
SPEC  fd.on 
SPEC  fd_cues 
SPEC  fd_no_cues 

—  search  for  ignored  crew  inputs 
DEFINE 

crew.input  :=  env_ev=ap_engaged_event  !  env_ev=fd_switch.hit  I 

env_ev=sync_switch_pressed  |  env.ev=sync_switch_released  | 

lateral_mode  .requested  I  vertical  .mode,  requested  I 

env_ev=vs.pitch_wheel.changed; 
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mode_change  := 

! (fd.mode=off  <->  AX  fd.mode=off)  I 
! (fd.mode=cues  <->  AX  fd.mode=cues)  I 
! (fd.mode=no_cues  <->  AX  fd.mode=no_cues)  | 


!  (lateral. roll. mode  =  cleared  <->  AX  lateral. roll. mode 

!  (lateral,  roll,  mode  =  active  <->  AX  lateral  .roll  .mode 

! (lateral .hdg. mode  =  cleared  <->  AX  lateral .hdg. mode 

!  (lateral. hdg. mode  =  active  <->  AX  lateral. hdg. mode 

! (lateral .ga. mode  =  cleared  <->  AX  lateral .ga. mode 

! (lateral.ga.mode  =  active  <->  AX  lateral.ga.mode 

! (lateral .nav. mode  =  cleared  <->  AX  lateral .nav. mode 

! (lateral. nav. mode  =  track  <->  AX  lateral. nav. mode 

! (lateral. nav. mode  =  armed_initial  <-> 

AX  lateral. nav. mode  =  armed_ initial) 

! (lateral. nav. mode  =  armed_long_enough  <-> 

AX  lateral. nav. mode  =  armed„long_ enough) 


cleared)  | 
active  )  I 
cleared)  | 
active  )  | 
cleared)  I 
active  )  | 
cleared)  I 
track  )  | 


I 


! (vertical .pitch. mode  =  cleared  <->  AX  vertical. pitch. mode  -  cleared)  | 
!  (vertical. pitch. mode  =  active  <->  AX  vertical. pitch. mode  =  active  )  | 
! (vertical. vs. mode  =  cleared  <->  AX  vertical .vs .mode  =  cleared)  I 
! (vertical. vs .mode  =  active  <->  AX  vertical . vs .mode  =  active  )  I 
!  (vertical. ga. mode  =  cleared  <->  AX  vertical.ga.mode  =  cleared)  I 
!  (vertical .ga. mode  =  active  <->  AX  vertical.ga.mode  =  active  ); 

search_for_ignored_crew_inputs  :=  AG  (crew.input  ->  mode_change) ; 


SPEC  search_f or_ ignored. ere w_ inputs 


—  property  violated 


—  no  unknown  ignored  crew  inputs 
DEFINE 

ignored.crew.input  : = 

(env_ev=ap_engaged_event  &  ! (lateral .ga.mode=active  I  vertical .ga.mode=active))  | 

(ev=ga_switch_hit  &  (lateral .ga.mode=active  &  vertical. ga.mode=active))  | 

PVS  model  too  strong  (may  be  left  out) 

(env_ev=sync_switch_pressed  &  ! (lateral. ga.mode=active  |  vertical. ga.mode=active))  | 
(ev=sync_switch_pressed  &  fd.mode=off)  I 

PVS  model  too  strong  (may  be  left  out) 

(env_ev=sync_switch_released)  I 

(env_ev=vs_pitch_wheel_changed  &  fd.mode=off)  I 
(env_ev=vs_pitch_wheel_changed  &  vertical  .pitch. mode=active)  ; 


no_known_ignored_crew_ inputs  := 

AG  (crew_input  &  ! ignored. crew_ input  ->  mode_change) ; 

SPEC  no_known_ ignored. crew_ inputs 
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—  search  for  indirect  mode  changes 
DEFINE 

search_f or_indirect_mode_changes  :=  AG  (! ere w_ input  ->  ! mode _ change ) ; 

SPEC  search.for.indirect.mode.changes  —  property  violated 

—  no  unknown  indirect  mode  changes 
DEFINE 

indirect .mode .change 

(env_ev=overspeed_start  &  ! (fd.mode=cues) )  | 

(env_ev=nav_armed_long_enough_event  &  lateral .nav.mode=armed_initial)  I 
(env.ev^nav.track.cond.met .event  &  lateral .nav.mode=armed.long_enough)  ; 

no.unknown.indirect.mode.change  := 

AG  ((! crew. input  &  ! indirect .mode. change)  ->  Imode.change)  ; 

SPEC  no.unknown.indirect.mode.change 


B.2.  Output  of  the  SMV  verifier. 

—  specification  fd.on.if .ap.engaged  is  true 

—  specification  at.least.one.lateral.mode.active  is  true 

—  specification  at.most.one.lateral.mode.active  is  true 

—  specification  at.least.one.vertical.mode.active  is  true 

—  specification  at.most.one.vertical.mode.active  is  true 

—  specification  fd.off .implies.all.modes. cleared  is  true 

—  specification  def ault.modes  is  true 

—  specification  hdg.selected.and.hdg.toggle.l  is  true 

—  specification  hdg.deselected  is  true 

—  specification  hdg.toggle_2  is  true 

—  specification  nav.selected.and.nav.toggle.l  is  true 

—  specification  nav.deselected  is  true 

—  specification  nav_toggle_2  is  true 

—  specification  vs.selected.and.vs.toggle.l  is  true 

—  specification  vs.deselected  is  true 

—  specification  vs_toggle_2  is  true 

—  specification  fd.off  is  true 

—  specification  fd.on  is  true 

—  specification  fd.cues  is  true 

—  specification  fd.no.cues  is  true 

—  specification  search.for.ignored.crew.inputs  is  false 

—  as  demonstrated  by  the  following  execution  sequence 

—  loop  starts  here  — 
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state  1.1: 

vg_select_default  =  0 
vg_ clear  =  0 

vg_sync_switch_pressed  =  0 
vg_ap_ engaged  =  0 
vg_ga_switch_hit  =  0 
vg_vs_svitch_hit  =  0 
vg_vs_pitch_vheel_changed  =  0 
lg_select_default  =  0 
lg.clear  =  0 

lg_nav_track_cond_met  =  0 
lg_nav_armed_long_enough  =  0 
lg_nav_switch_hit  =  0 
lg_sync_switch_pressed  =  0 
lg_ap_engaged  =  0 
lg_ga_switch_hit  =  0 
lg_hdg_switch_hit  »  0 
fd.overspeed  =  0 
fd_ap_engaged  =  0 
fd_turn_off  =  0 
fd_switch  =  0 
fd_turn_on  =  0 
fd_f orce_cues  =  0 
flight _director_event  =  0 
vertical_mode_requested  =  0 
1 at eral_mode .requested  =  0 
fd_is_on  =  0 
new_ap_engaged  =  0 
new_overspeed  =  0 

all_events  =  hdg_switch„hit  ,nav_switch„hit  ,nav_armed. 

fd_on_if_ap_engaged  =  1 

at_least_one_lateral_mode_active  =  1 

at_most_one_lateral_mode_active  =  1 

at_least_one_vertical_mode_active  =  1 

at_most_one_vertical_mode_active  =  1 

fd_off _implies_all_modes_cleared  =  1 

default_modes  -  1 

hdg_toggle_2  =  1 

hdg.deselected  =  1 

hdg_selected_and_hdg_toggle_l  =  1 

nav_toggle_2  =  1 

nav^deselected  =  1 

nav_selected_and„nav_toggle_l  =  1 

vs_toggle_2  =  1 

vs_deselected  =  1 

vs_selected_and_vs_toggle_l  =  1 

fd_no_cues  =  1 
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fd.cues  =  1 
fcLon  =  1 
fd.off  »  1 

search.for.ignored.crew.inputs  =  0 
mode .change  =  0 
crew. input  =  1 

no.known.ignored.crew.inputs  *  1 

ignored. crew. input  =  1 

sear ch.f or. indirect .mode. changes  =  0 

no.unknown. indirect .mode .change  =  1 

indirect .mode. change  =  0 

env.ev  -  sync.switch.released 

overspeed  =  0 

ap.engaged  -  0 

fd.turned.off  =  0 

fd.turned.on  -  0 

fd.mode.on  =  0 

fd.mode  =  off 

lateral.nav.event  =  0 

lateral . Iga.event  =  0 

lateral .hdg.event  =  0 

lateral. nav.armed.long.enough  =  0 

lateral. nav.track.cond.met  =  0 

lateral. nav.clear  =  0 

lateral. nav.switch  =  0 

lateral.nav.deactivate  =  0 

lateral.nav.activate  =  0 

lateral .ga.clear  =  0 

lateral. ga.switch  =  0 

lateral. ga.deactivate  *  0 

lateral.ga.activate  =  0 

lateral. hdg. clear  =  0 

lateral. hdg. switch  *  0 

lateral. hdg.deactivate  =  0 

lateral. hdg.activate  =  0 

lateral. roll.clear  =  0 

lateral .roll. switch  -  0 

lateral. roll.deactivate  =  0 

lateral.roll.activate  =  0 

lateral .roll .deactivated  =  0 

lateral. roll. activated  =  0 

lateral. roll. mode  =  cleared 

lateral .hdg. deactivated  =  0 

lateral .hdg. activated  =  0 

lateral. hdg. mode  =  cleared 

lateral.ga. deactivated  -  0 

lateral. ga. activated  =  0 
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lateral .ga. mode  =  cleared 
lateral. nav. deactivated  =  0 
lateral .nav. activated  =  0 
lateral. nav. mode.active  =  0 
lateral .nav. mode.armed  =  0 
lateral. nav. track_cond  =  0 
lateral. nav. mode  =  cleared 
lateral. nav. t rack. cond_met  =  0 
vert i cal. vga.e vent  =  0 
vertical. vs.event  =  0 
vertical. pitch.event  =  0 
vertical.ga.clear  =  0 
vertical. ga.switch  =  0 
vertical.ga.deactivate  =  0 
vertical. ga.activate  =  0 
vertical. vs .clear  =  0 
vertical. vs. switch  =  0 
vertical. vs .deactivate  =  0 
vertical. vs.activate  =  0 
vertical .pitch.clear  =  0 
vertical. pit ch.switch  =  0 
vertical. pitch.deactivate  =  0 
vertical.pitch.activate  =  0 
vertical. pitch. deactivated  =  0 
vertical. pitch. activated  =  0 
vertical. pitch. mode  =  cleared 
vertical. vs .deactivated  =  0 
vertical. vs . activated  =  0 
vertical. vs. mode  =  cleared 
vert ical.ga. deactivated  =  0 
vertical. ga. activated  =  0 
vertical.ga.mode  =  cleared 

state  1.2: 

—  specification  no .known. ignored. crew. inputs  is  true 

—  specification  search.for.indirect.mode.changes  is  false 

—  as  demonstrated  by  the  following  execution  sequence 
state  2.1: 

vg.select.default  =  0 
vg.clear  =  0 

vg.sync.switch.pressed  =  0 
vg.ap.engaged  =  0 
vg.ga_switch.hit  =  0 
vg.vs_switch.hit  =  0 
vg.vs.pitch.wheel. changed  =  0 
lg.select .default  =  0 
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lg.clear  =  0 

lg_nav_track_cond_met  =  0 
lg.nav. armed. long, enough  =  0 
lg.nav.switch.hit  =  0 
lg_sync_switch_pressed  =  0 
lg_ap_engaged  =  0 
lg_ga.switch.hit  =  0 
lg.hdg.switch.hit  =  0 
fd.overspeed  =  0 
fd.ap.engaged  =  0 
fd.turn.off  =  0 
fd.switch  =  0 
fd.turn.on  =  0 
fd.force.cues  =  0 
flight _director_event  =  0 
vertical.mode.requested  =  0 
lateral.mode.requested  =  0 
fd_is_on  =  0 
new.ap.engaged  =  0 
new.overspeed  =  0 

all.events  =  hdg.switch.hit ,nav_switch_hit , 
fd_on_if_ap_engaged  =  1 
at.least.one.lateral.mode.active  =  1 
at.most.one.lateral.mode.active  =  1 
at.least.one.vertical.mode.active  =  1 
at.most.one.vertical.mode.active  =  1 
fd.off.implies.all.modes.cleared  *  1 
default .modes  =  1 
hdg_toggle_2  =  1 
hdg.deselected  =  1 
hdg.selected.and.hdg.toggle.l  =  1 
nav_toggle_2  =  1 
nav.deselected  =  1 
nav.selected.and.nav.toggle.l  =  1 
vs_toggle.2  =  1 
vs.deselected  =  1 
vs.selected.and.vs.toggle.l  =  1 
fd_no_cues  =  1 
fd.cues  =  1 
fd_on  =  1 
fd.off  =  1 

search.for.ignored.crew.inputs  =  0 
mode. change  =  0 
crew. input  =  1 

no.known.ignored.crew.inputs  =  1 
ignored. crew. input  =  1 
search.for_indirect_mode_changes  =  0 


no_unknown_indirect_mode_ change  =  1 

indirect_mode .change  =  0 

env.ev  =  sync_switch_released 

overspeed  =  0 

ap_ engaged  =  0 

fd.turned_.off  =  0 

fd.turned.on  =  0 

fd.mode_.on  =  0 

fd.mode  =  off 

lateral . nav.event  =  0 

lateral. lga.event  =  0 

lateral. hdg.event  =  0 

later  al.nav_armed_long_enough  =  0 

lateral .nav_t rack. cond.met  =  0 

lateral. nav.clear  =  0 

lateral. nav.switch  =  0 

lateral. nav.deactivate  =  0 

lateral. nav.activate  =  0 

1 at eral.ga. clear  =  0 

lateral. ga.switch  =  0 

lateral .ga.deactivate  =  0 

lateral . ga.activate  =  0 

lateral .hdg.clear  =  0 

lateral. hdg.switch  -  0 

lateral. hdg.deactivate  =  0 

later al.hdg.activate  =  0 

lateral. roll.clear  =  0 

lateral .roll.switch  =  0 

lateral. roll.deactivate  =  0 

lateral .roll.activate  =  0 

lateral. roll. deactivated  =  0 

lateral. roll. activated  =  0 

lateral. roll. mode  =  cleared 

lateral. hdg. deactivated  =  0 

lateral. hdg. activated  -  0 

lateral. hdg. mode  =  cleaxed 

lateral. ga. deactivated  =  0 

lateral. ga. activated  =  0 

lateral. ga. mode  -  cleared 

lateral. nav. deactivated  =  0 

lateral. nav. activated  =  0 

lateral. nav. mode.active  =  0 

1 at eral. nav. mode _ armed  =  0 

lateral. nav. track.cond  =  0 

lateral. nav. mode  =  cleared 

lateral. nav. track_cond_met  =  0 

vertical. vga_event  =  0 
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vertical. vs_event  =  0 
vert i cal. pit ch.e vent  =  0 
vert i cal. ga.clear  =  0 
vertical. ga_switch  =  0 
vertical. ga_deactivate  =  0 
vertical .ga_activate  =  0 
vertical. vs_clear  =  0 
vertical. vs. switch  =  0 
vertical. vs_deactivate  =  0 
vertical .vs_activate  =  0 
vertical. pitch_clear  =  0 
vertical. pitch_switch  =  0 
vertical. pitch.deactivate  =  0 
vertical,  pit  deactivate  =  0 
vertical. pitch. deactivated  =  0 
vertical. pitch. activated  =  0 
vertical. pitch. mode  =  cleared 
vertical. vs. deactivated  =  0 
vertical. vs . activated  =  0 
vertical. vs. mode  =  cleared 
vertical. ga. deactivated  =  0 
vertical.ga. activated  =  0 
vert i cal. ga.  mode  =  cleared 

state  2.2: 

vg.select.def ault  *  1 
lg_select_default  =  1 
fd_overspeed  =  1 
fd.force.cues  =  1 
flight_director_event  =  1 
fd_is_on  =  1 
new.overspeed  =  1 
mode .change  =  1 
crew. input  =  0 
ignored. crew. input  =  0 
indirect_mode_change  =  1 
env.ev  =  overspeed.start 
fd.turned.on  =  1 
lateral. roll.activate  =  1 
lateral. roll. activated  =  1 
vertical. pitch.activate  =  1 
vertical. pitch. activated  =  1 

state  2.3: 

vg.select.default  =  0 
lg.select.default  =  0 
fd.force.cues  =  0 


flight_director_event  -  0 
mode_change  =  0 
crew_ input  =  1 
ignored_crew_ input  =  1 
indirect _mode_ change  -  0 
env_ev  =  sync_switch_released 
overspeed  =  1 
fd.turned_on  =  0 
fd.mode_on  =  1 
fd.mode  =  cues 
later al.roll_activate  =  0 
lateral .roll. activated  =  0 
lateral. roll. mode  =  active 
vertical.pitch_activate  =  0 
vertical .pitch. activated  =  0 
vertical. pitch. mode  =  active 

—  specification  no_unknown_indirect_mode_ change  is  true 
resources  used: 

user  time:  0.58  s,  system  time:  0.17  s 
BDD  nodes  allocated:  5940 
Bytes  allocated:  983040 

BDD  nodes  representing  transition  relation:  438  +  1 
reachable  states:  3388  (2~11.7262)  out  of  86016  (2~ 16. 3923) 
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Appendix  C.  Specification  and  Verification  Using  Spin. 

C.l.  Full  Model  of  the  Mode  Logic. 

/**  values  of  modes  ********.*****************************************************************/ 


ttdefine  cleared  0 
#define  active  1 
#define  track  2 
#define  armed_initial  3 
#define  armed.long.enough  4 
#define  off  5 
#define  cues  6 
#define  no.cues  7 


/**  events  and  signals  **********************************************************************/ 

mtype  =  {  /*  environment  events  */ 

hdg_switch_hit ,  nav_switch_hit , 

nav.armed.long.enough.event ,  nav„track.cond_met_event , 
ga.switch.hit ,  vs_pitch_wheel_changed, 

vs_switch_hit ,  fd_switch_hit , 

overspeed.start ,  overspeed_stop, 

ap_engaged_event ,  ap.disengaged.event , 

sync.switch.pressed ,  sync_switch_released , 

/*  simple  guidance,  arming  guidance  and  flight  director  events  */ 

clear,  activate, 

deactivate,  switch, 

turn_on ,  turn-off , 

f orce.cues ,  armed_long_enough.event , 

track. cond.met .event , 

/*  signals  */ 
activated, 
turned_on, 
null 

> 

typedef  ag.state  {  byte  mode  =  cleared; 

bool  track. cond.met  =  false 

>; 

/**  variables  controled  by  the  environment  **************************************************/ 

bool  overspeed  =  false; 

bool  ap.engaged  =  false; 


deactivated, 
turned.off , 
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/**  mode  and  signal  variables  &  variable  for  env.  event  *************************************/ 

bit  pitch  =  cleared;  bit  old_pitch  =  cleared; 

bit  vs  =  cleared;  bit  old_vs  =  cleared; 

bit  vga  =  cleared;  bit  old_vga  =  cleared; 

bit  roll  =  cleared;  bit  old_roll  =  cleared; 

bit  hdg  -  cleared;  bit  old_hdg  =  cleared; 

bit  lga  =  cleared;  bit  old_lga  =  cleared; 

byte  fd  =  off;  byte  old.fd  =  off; 

ag_state  nav;  ag_state  old_nav; 

mtype  pitch.signal  =  null;  mtype  vs_signal  =  null; 

mtype  vga„signal  =  null;  mtype  roll_signal  =  null; 

mtype  hdg_signal  =  null;  mtype  Iga.signal  -  null; 

mtype  nav_signal  =  null;  mtype  fd_signal  =  null; 

mtype  env_ev  =  null; 

/**  useful  abbreviations  ********************************************************************/ 
#define  lateral_mode_requested 

( (env_ev==hdg_switch_hit)  II  (env_ev==nav_switch„hit)  I  I  (env_ev==ga_switch_hit)) 

#define  vertical_mode_requested 

((env_ev==vs_switchwhit)  ||  (env_ev==ga_switchjiit) ) 

inline  f ligbt_director_event (env_ev)  {  (env_ev==ap„engaged_event)  I j 

(env_ev==fd_switch_hit)  I  I 

(env_ev==overspeed_start)  |  | 

lateral_mode_requested  I  I 

vertical_mode_requested 

} 

/**  auxiliary  "functions"  *******************************************************************/ 

inline  hdg_event (env_ev)  {  env_ev==hdg_switch_hit  } 

inline  nav_event (env_ev)  {  (env_ev==nav_svitch_hit)  j  | 

(env_ev==nav_armed„long_enough_event)  I  I 

(env_ev-=nav_track_cond_met„event) 

> 

inline  Iga.event (env^ev)  {  (env_ev==ga_switch_hit)  I  | 

(env_ev==ap_engaged_event)  I  | 

(env_ev==sync_switch_pressed) 

} 
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inline  pitch.event (env.ev)  {  env_ev==vs_pitch_wheel_changed  } 
inline  vs.event (env.ev)  {  env_ev==vs_switch_hit  > 

inline  vga.event (env_ev)  {  (env_ev==ga_switch_hit)  I  I  (env_ev==ap_engaged_event)  I  I 

(env_ev==sync_switch_pressed) 

> 

/**  abstract  data  type  module  simple  guidance  ***********************************************/ 

inline  simple_guidance(mode,  e 

{ 

if 

: :  mode==cleared  -> 
if 

: :  event==activate  -*> 

: :  event==deactivate  -> 

: :  event==switch  -> 

: :  event==clear  -> 

fi 

: :  mode==active  -> 
if 

: :  event==activate  ~> 

: :  event==deactivate  -> 

: :  event==switch  -> 

: :  event==clear  -> 

fi 
fi 

> 

/**  abstract  data  object  module  arming  guidance  *********************************************/ 
inline  arming.guidance (event ,  signal) 
if 

::  nav.mode==cleared  -> 
if 


event==activate 

->  nav.mode 

=armed_ initial; 

signal 

=activated 

event==deactivate 

->  signal 

=null 

event==switch 

->  nav.mode 

=armed_initial ; 

signal 

=activated 

event==clear 

->  signal 

=null 

event==armed.long.enough_event 

->  signal 

=null 

event==track_cond.met .event 

->  nav. track. 

.cond_met=true ; 

signal 

=null 

fi 


vent,  signal) 


mode=active; 


mode=active ; 


signal=activated 
signal=null 
signal=activated 
signal =null 


signal=null 
mode=cleared;  signal=null 
mode=cleared;  signal=deactivated 
mode=cleared;  signal=deactivated 
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: :  else 
if 


-> 


fi 

> 


: :  event ==acti vat e 
: :  event==deactivate 

: :  event==switch 

: :  event==clear 

: :  event==armed_long_enough_event 
if 

::  (nav.mode==armed_initial) 
nav . track_cond_met 

::  (nav.mode==armed_initial) 
! nav . track. cond_met 

: :  else 
fi 

: :  e vent ==track_cond_met. event 
if 


”>  signal  =null 
->  nav.mode=cleared; 

signal  =null 
->  nav.mode=cleared; 

signal  =deactivated 
->  nav.mode=cleared; 
signal  =deactivated 

-> 

&& 

->  nav.mode=track; 
signal  =null 

&& 

->  nav.mode=armed_long_enough; 

signal  =null 
->  signal  =null 

-> 


::  nav.mode=i=armed_long_enough  ->  nav. mode  =track; 

nav . track_cond_met=true ; 
signal  =null 

::  else  ->  nav.track_cond_met=true; 

signal  =null 


fi 


fi 


/**  function  module  lateral  guidance  ********************************************************/ 

inline  lateral_guidance(env_ev) 

{ 

if 

::  hdg.event (env.ev)  -> 

simple.guidance(hdg,  switch,  hdg.signal) ; 
if 


fi 


hdg_signal==activated  ->  simple_guidance(roll,  deactivate,  roll.signal) ; 

simple_guidance(lga,  deactivate,  lga.signal  ); 

arming_guidance (  deactivate,  nav.signal  ) 

hdg_signal==deactivated  ->  simple.guidance (roll ,  activate,  roll.signal) 

else  ->  skip 
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::  nav.event(env.ev)  -> 
if 


: :  env_ev==nav„switch_hit  -> 

arming.guidance (switch,  nav.signal) 

: :  env_ev==nav_track_cond_met_event  -> 

arming.guidance  (track.cond.met .event ,  nav.signal) 

: :  env_ev==nav_armed_long_enough_event  -> 

arming.guidance (armed.long.enough.event ,  nav.signal) 
fi; 


if 


: :  nav_signal==activated  -> 

: :  nav_signal==deactivated  -> 
: :  else  -> 


simple.guidance (roll,  deactivate, 
simple.guidance  (hdg,  deactivate , 
simple.guidance  (lga,  deactivate, 
simple_guidance(roll,  activate, 
skip 


roll.signal) ; 
hdg. signal  ) ; 
lga.signal  ) 
roll.signal) 


fi 


: :  Iga.event (env.ev)  -> 
if 

::  env__ev==ga_ switch_h.it  ->  simple_guidance(lga,  activate,  lga.signal) 

—  else  ->  simple.guidance (lga,  clear,  lga.signal) 

fi; 

if 

::  lga_signal==activated  ->  simple_gnidance(roll,  deactivate,  roll.signal); 

simple.guidance (hdg ,  deactivate,  hdg.signal  ); 

arming.guidance (  deactivate,  nav.signal  ) 

::  lga.signal==deactivated  ->  simple.guidance (roll ,  activate,  roll.signal) 

: :  else  ->  skip 

fi 


: :  else  ~> 

skip 
fi 


/**  function  module  vertical  guidance  *********♦*********************************♦***♦♦♦**♦**/ 

inline  vertical.guidance(env.ev) 

{ 

if 

::  pitch.event (env.ev)  -> 

simple.guidance (pitch,  activate,  pitch.signal)  ; 
if 

::  pitch_signal==activated  ->  simple.guidance  (vs,  deactivate,  vs. signal  ); 

simple.guidance (vga,  deactivate,  vga.signal) 

: :  else  ->  skip 

fi 
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::  vs.event (env_ev)  -> 

simple.guidance (vs ,  switch,  vs.signal) ; 
if 

::  vs_signal==activated  ->  simple.guidance (pitch,  deactivate,  pitch.signal); 

simple.guidance  (vga,  deactivate,  vga.signal  ) 

::  vs_signal==deactivated  ->  simple .guidance (pitch,  activate,  pitch.signal) 

: :  else  ->  skip 

fi 

: :  vga.event (env.ev)  -> 
if 

::  env_ev==ga_switch_hit  ->  simple.guidance  (vga,  switch, vga.signal) 

::  else  ->  simple.guidance  (vga,  clear,  vga.signal) 

fi; 

if 

::  vga.signal==activated  ->  simple.guidance (pitch,  deactivate,  pitch.signal) ; 

simple.guidance (vs,  deactivate,  vs. signal  ) 

::  vga_signal==deactivated  ->  simple.guidance (pitch,  activate,  pitch.signal) 

: :  else  ->  skip 

fi 

: :  else  -> 

skip 
fi 

> 

/**  abstract  data  object  module  flight  director  ********************************************/ 
inline  flight.director (event ,  signal) 
if 

::  fd==off  -> 

if 

::  event==f orce.cues  ->  fd=cues;  signal^turned.on; 

::  event ==turn_on  ->  fd=cues;  signal=turned_on 

::  event ==s witch  ->  fd=cues;  signal=turned.on 

: :  event==turn_off  ->  signal=null 

fi 

: :  f d==cues  -> 

if 

: :  event==f orce.cues  ->  signal=null 
: :  e vent == turn. on  ->  signal=null 
: :  event==switch  -> 
if 

: :  overspeed  I !  ap.engaged  ->  f d=no_cues ;  signal=null 

::  else  ->  fd=off;  signal=turned_off 

fi 
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: :  event==turn.off  -> 
if 

::  overspeed  ||  ap.engaged  ->  fd=no_cues;  signal=null 
::  else  ->  fd=off;  signal=turned_off 

fi 
fi 

: :  else  -> 

if 

::  event==force_cues  ->  fd=cues;  signal=null 

::  event==turn_on  ->  fd=cues;  signal=null 

: :  event==switch  -> 

if 

: :  overspeed  I  I  ap.engaged  ->  f d=cues ;  signal =null 

: :  else  ->  f d=of  f ;  signal =tumed_off 

fi 

: :  event==turn.off  -> 

if 

: :  overspeed  I  I  ap_engaged  ->  signal =null 

::  else  ->  fd=off;  signal=turned_off 

fi 
fi 
fi 

} 

/**  mandatory  and  mode  confusion  properties  as  assertions  ***********************************/ 
#define  nav_active 

( (nav. mode ==armed. initial)  I |  ( nav. mode == armed. long. enough)  | |  (nav.mode==track)) 

#define  crew. input 

( (env_ev==ap_engaged_event) 

(env_ev==sync_switch_released) 
lateral.mode.requested 
(env_ev==vs.pitch_wheel_changed) ) 

#define  ignored. crew_ input 

( ( (env_ev==ap_engaged_event)  &&  ! ( (old.lga==active) | | (old_vga==active) ) )  |  | 

( (env.ev==sync.switch_pressed)  &&  !  ((old.lga==active) I  I (old.vga==active)) )  |  | 

(env_ev==sync.switch_released)  | | 

( (env_ev==vs.pitch.vheel_changed)  &&  (old_f d==of f ) )  I  | 

( (env_ev==vs.pitch_wheel_changed)  &&  (old_pitch==active))) 

#define  indirect .mode .change 

( ( (env_ev==overspeed_start)  &&  ! (old.fd==cues) )  II 

( (env_ev==nav_armed.long_enough_event)  &&  (old.nav.mode==armed_initial) )  II 

( (env_ev==nav.track_cond_met. event)  &&  (old_nav.mode==armed.long_enough) ) ) 


I  I  (env_ev==sync_switch.pressed)  | | 
I  I  (env.ev==fd_switch_hit)  I  I 
I  |  vertical.mode.requested  I  I 
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#define  mode_change 

((fd  !=  old_fd)  ||  (pitch  !=  old_pitch)  I  I  (vs  !=  old_vs)  I  I  (vga  !=  old.vga)  II 

(roll  !=  old.roll)  ||  (hdg  !=  old.hdg)  ||  (lga  !=  old.lga)  || 

(nav.mode  !=  old_nav.mode) ) 

inline  mandatory_and_mode_confusion_properties (env_ev) 

/**  the  flight  director  is  on  if  the  autopilot  is  engaged  **/ 
assert ( ! ap_engaged  I  I  ! (f d==of f ) ) ; 

/**  at  least  one  lateral  mode  is  active  iff  the  flight  director  is  on  **/ 

assert (( (fd==off)  If  (roll==active  II  hdg==active  ||  lga==active  I  I  nav_active))  && 

( ! (roll==active  II  hdg==active  II  lga==active  I  I  nav.active)  I  I  !(fd==off)) 

); 


/**  there  is  never  more  than  one  lateral  mode  active  **/ 

assert ((! (lga  “active)  ||  (roll==cleared  &&  hdg==cleared  &&  nav.mode==cleared) )  && 

(! (roll==active)  I  I  (lga==cleared  &&  hdg== cleared  &&  nav.mode==cleared))  && 

(!(hdg  ==active)  II  (roll==cleared  &&  lga==cleared  &&  nav.mode==cleared) )  && 

( !  (nav_active)  I  I  (roll==cleared  &&  hdg“cleared  &&  lga  “cleared)) 

); 


/**  at  least  one  vertical  mode  is  active  iff  the  flight  director  is  on  **/ 
assert (((fd==off)  I  I  (vga==active  II  vs==active  II  pitch==active) )  && 

( i (vga==active  | |  vs==active  | |  pitch==active)  II  !(fd==off)) 

); 


/**  at  most  one  vertical  mode  is  active  **/ 

assert((! (vga  “active)  II  (pitch==cleared  &&  vs==cleared) )  && 

(j (vs  ==active)  I  I  (pitch==cleared  &&  vga==cleared) )  ft& 

(!  (pitch==active)  I  I  (  vga—cleared  &fc  vs==cleared) ) 

); 


/**  if  the  flight  director  is  off,  all  modes  must  be  cleared  **/ 


assert ( ! (fd==off ) 


); 


I  |  (pitch=-cleared  &&  vs==cleared  &&  vga==cleared  &&  roll==cleared  && 
hdg==cleared  &&  lga==cleared  &&  nav.mode==cleared) 


/**  the  default  modes  are  active  if  the  flight  director  is  on  and  **/ 
/**  all  other  modes  are  cleared  **/ 


assert (!(!  (fd“off)  &&  vs==cleared  &&  vga==cleaxed  && 

hdg==cleared  &&  lga==cleared  &&  nav . mode==cleared 
)  I  I  (pitch“active  &&  roll==active) 

); 
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/**  mandatory  properties  **/ 
if 

: :  env_ev==hdg_switch_hit  -> 

/**  check  for  response  to  pressing  HDG  button  **/ 
assert ( ! (old_hdg==cleared)  | |  (  hdg==active  ) ) ; 
assert (! (old_hdg==active  )  ||  (roll==active  )); 
assert (! (old.hdg==active  )  11  (  hdg==cleared) ) 

: :  env.ev—nav.switch.hit  -> 

/**  check  for  response  to  pressing  NAV  button  **/ 

assert (! (old.nav .mode==cleared)  ||  ( (nav.mode== armed. initial)  II 

(nav.mode—armed.long.enough)  |  I  (nav.mode==track) 

) 

); 

assert ( ! ( (old_nav.mode==armed_initial)  ||  (old_nav.mode==armed_long_enough)  I  I 
(old.nav .mode==t rack) 

)  I  I  (roll==active) 

); 

assert (!( (old_nav.mode==armed_initial)  ||  ( old.nav. mode==armed_long_enough)  || 

(old.nav .mode==track) 

)  | I  (nav.mode==cleared) 

) 

: :  env_ev==vs_switch.hit  -> 

/**  check  for  response  to  pressing  VS  button  **/ 
assert (! (old.vs==cleared)  ||  (vs==active)) ; 
assert (! (old_vs==active  )  |]  (pitch==active) ) ; 
assert (! (old_vs==active  )  II  (vs==cleared) ) 

: :  env_ev==fd_switch.hit  ~> 

/**  check  for  response  to  pressing  the  FD  button  **/ 
assert (! (old.fd==off )  ||  (fd==cues)); 

assert ( ( ! ( ! (old_f d==of f )  &&  ! (ap.engaged  II  overspeed)))  ||  (fd==off)); 
assert (! ((old_fd==cues)  &&  (ap.engaged  I  I  overspeed))  I  I  (fd==no.cues) ) ; 
assert (! ( (old_fd==no_cues)  &&  (ap.engaged  II  overspeed))  ||  (fd==cues)); 

: :  else  -> 
skip 

fi; 

/**  search  for  ignored  crew  inputs  **/ 

/**  assert (! (crew.input)  ||  mode.change) ;  **/ 

/**  property  violated  **/ 

/**  no  unknown  ignored  crew  inputs  **/ 

assert ( ! (crew.input  &&  ! (ignored. crew.input) )  I  I  mode.change) ; 
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/**  search  for  indirect  mode  changes  **/ 

/**  assert (!(! (crew.input) )  II  ! (mode _ change) ) ;  **/ 

/**  property  violated  **/ 

/**  no  unknown  indirect  mode  changes  **/ 

assert (!(! (crew.input)  &&  !  (indirect_mode_change) )  I  I  ! (mode „ change) ) ; 

/**  save  the  current  mode  values  **/ 

old_pitch  -  pitch;  old_vs  =  vs;  old.vga  =  vga;  old^roll  =  roll; 

old_hdg  =  hdg;  old_lga  -  Iga;  old_fd  =  fd; 

old_nav.mode  =  nav.mode;  old_nav.  track_cond__met  =  nav.track_cond_met 

} 

/******************************************♦*******************************♦*****************/ 

inline  clear_all_modes() 

{ 

pitch=cleared;  vs=cleared;  vga=cleared;  roll=cleared; 

hdg=cleared;  lga=cleared;  nav.mode=cleared 

> 

/**************************♦*****************♦*****************************************♦*****/ 

inline  select_def ault_mode() 

{ 

pitch=active;  roll=active 

> 

/**♦*♦♦****************♦***********♦*******************♦*******♦*****************************/ 

inline  process_external_event (env_ev) 

{ 

if 

: :  env_ev==ap_engaged_event  ->  ap _ engage d= true 

: ;  env_ev==ap_disengaged_event  ->  ap_engaged=f alse 

: :  env_ev==overspeed_start  ->  overspeed  =true 

: :  env_ev-=overspeed_stop  ->  overspeed  =false 

: :  else  ->  skip 

fi 

> 

/**************************************************************+******♦****♦*****************/ 
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inline  process.fd.event (env.ev) 

{ 

if 

::  f light. director.event (env.ev)  -> 
if 


: :  env_ev==fd_switch_hit 

-> 

flight .director (switch,  fd.signal) 

: :  env_ev==overspeed_start 

-> 

flight_director(force.cues,  fd.signal) 

: :  else 

~> 

flight .director (turn.on ,  fd.signal) 

fi; 

if 

: :  fd_signal==turned_off 

-> 

clear.all.modes () 

: :  f d_signal==turned_on 

-> 

select.def ault.mode () 

: :  else 

-> 

skip 

fi 

else 

-> 

skip 

fi 

> 

/♦♦♦♦♦♦Jlc***************^************************^**********^*^^*********^***^*^^^*^*****^***^/ 

inline  process.f light .mode.event (env.ev) 

{ 

if 

::  ! (fd==off )  ->  lateral.guidance (env.ev) ;  vertical.guidance  (env.ev) 

: :  else  ->  skip 

fi 

> 

/****************************************************+********************************+******/ 

inline  clear. signals () 

{ 

pitch.signal  =  null;  vs.signal  =  null;  vga.signal  =  null;  roll.signal  =  null; 
hdg.signal  =  null;  lga_signal  =  null;  nav.signal  =  null;  fd.signal  =  null 

> 

/**  main  module  performing  modeling  one  synchronous  step  of  the  system  **********************/ 

inline  fgs (env.ev) 

{ 

process.external.event (env.ev) ; 
process.fd.event (env.ev) ; 
process.f light.mode .event (env.ev) ; 

clear.signalsO  ;  /**  signals  are  no  longer  needed  **/ 

mandatory.and.mode.confusion.properties  (env.ev) 

> 
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/**  init  process,  including  model  of  the  environment  ****************************************/ 

init{  end.main:  do  ::  atomic{  if  /*  nondeterministically  choose  env.  event  */ 

: :  env_ev=hdg_switch_hit 
: :  env_ev=nav_switch_hit 
: :  env_ev=nav_armed_long_enough_ event 
: :  env_ev=nav_track_cond_met_event 
: :  env_ev=ga_svitch_hit 
::  env_ev=vs_pitch_wheel_changed 
: :  env_ev=vs_switch_hit 
: :  env_ev=fd_switch_hit 
: :  env_ev=overspeed_start 
: :  env_ev=overspeed_stop 
: :  env_ev=ap_engaged_event 
: :  env_ev=ap_disengaged_event 
: :  env_ev=sync_switch_pressed 
: :  env_ev=sync_switch_released 

fi; 

fgs(env_ev);  /*  perform  synchronous  step  */ 

env_ev=null  /*  env.  event  is  no  longer  needed  */ 

> 

od  > 

/*****************************♦♦******************♦*************************************♦****/ 

C.2.  Output  of  the  Spin  verifier. 

(Spin  Version  3.2.4  —  10  January  1999) 

Full  statespace  search  for: 
never-claim  -  (none  specified) 

assertion  violations  + 

cycle  checks  -  (disabled  by  -DSAFETY) 

invalid  ends t ate s  + 

State-vector  32  byte,  depth  reached  4151,  errors:  0 
242  states,  stored 
3147  states,  matched 
3389  transitions  (=  stored+matched) 

165976  atomic  steps 
hash  conflicts:  0  (resolved) 

(max  size  2*19  states) 

2.604  memory  usage  (Mbyte) 

real  1 . 9 

user  1.7 

sys  0.2 
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